Slack: orchestrator won't post replies delivered as a bracketed paste (pasted-instruction refusal) #694

Version: 0.5.5 (Windows 10, Electron build)
Provider: Claude via subscription — claude --model claude-opus-…[1m] --permission-mode bypassPermissions
Slack mode: Socket Mode, channel C0C0LCFJR71

Summary

When a Slack @mention is relayed to the orchestrator ("god" / Michael), the harness
injects it into the Claude Code session as a bracketed paste (the TUI shows
[Pasted text #N +7 lines]). Claude Code then applies its anti-prompt-injection
safeguard and declines to take an outward action — posting back to Slack — on
instructions that arrived purely as pasted text. The agent reads the message and
even drafts the reply, then refuses to send it without a human saying "yes."

Net effect: the user posts an @mention, the bot never replies, and it looks broken.

Observed behavior (verbatim from the agent's terminal)

"Yes, I can see it… I haven't posted anything to Slack yet. This whole request
came in as pasted text with no message of your own around it, and I don't post to
an outside service on pasted instructions alone. If you want the reply posted,
say so…"

The harness's own [SLACK REQUEST] block does instruct the agent to post (it
includes the reply command), but that instruction is discounted because it lives
inside the untrusted paste. The agent ends up idle with its own "Yes, post it"
sitting unsent in the input line.

Reproduction

1. Slack in Socket Mode, bot invited to the channel, provider = Claude CLI on a
   subscription (bypassPermissions).
2. @mention the bot in the channel with a plain request.
3. Manually submit the pasted prompt to the agent (see the related stuck-submit
   issue; you may need to press Enter in the terminal).
4. Observe: the agent processes the message but declines to post the reply, stating
   it won't act on pasted instructions alone.

Why it happens

Claude Code intentionally treats large pasted content as untrusted data and will
not perform outward/side-effecting actions based on it — an anti-prompt-injection
measure. The harness delivers Slack messages as exactly that kind of paste, so the
safeguard fires on every relayed request.

Suggested fixes

• Deliver the relayed Slack message as a normal conversation turn, not a raw
  bracketed paste, so it is not flagged as untrusted pasted data.
• And/or place the standing grant ("you are authorized to reply in your own Slack
  channel") in a trusted location — the system prompt or project memory
  (CLAUDE.md) — rather than inside the pasted block. (A user-side CLAUDE.md
  authorizing replies does appear to resolve it, which confirms the mechanism.)
• Over an API transport this safeguard would not trigger at all, since there is no
  "paste"; that is further evidence the paste-into-TUI delivery is the root cause.

Notes

• Related issue: PTY auto-submit of the injected prompt intermittently gets stuck
  (filed separately).
• Screenshot available: the orchestrator's "I don't post on pasted instructions
  alone" reply with > Yes, post it unsent in the input line.