fix(daemon): suppress Claude Code's built-in SendMessage on managed sessions

[stkevintan]

What

Disallow Claude Code's built-in agent-teams SendMessage tool on every AgentConnect-managed Claude session, via _meta.claudeCode.options.disallowedTools at session/new and session/load. This is fix 1 of #800 — the mechanism-level suppression — and closes the misdelivery channel #998 caught live.

Why

• A subject agent's runtime built-in peer messaging can exfiltrate session-private content to unrelated local sessions #998: the built-in tool is not a black hole — it delivered a game-private night action to an unrelated local Claude session on the same machine. The artifact audit found the built-in channel reached in every one of nine trials (4–9 calls each).
• feat(daemon): infer the parent reply when a needsReply delegation turn ends without its report #984 (inferred reply, merged) recovers lost reports but cannot recover content that already left the process; fix(daemon): scope the #800 SendMessage-collision fix to the parent-report directive #905's directive-level mitigation covers only the needsParentReply child population — its own A/B run showed the collision also firing on the caller side, which only adapter-level suppression reaches.

How

• CLAUDE_DISALLOWED_BUILTIN_TOOLS = ['SendMessage'] in runtime-defs/claude-runtime.ts
• claudeSessionMeta() now always includes disallowedTools in claudeCode.options, so both newSession and loadSession carry it
• claude-agent-acp spreads claudeCode.options into the SDK query() options layer, which natively supports disallowedTools; older adapters ignore the unknown option (same degradation pattern as settings / systemPrompt)
• Runtime-gated by construction: claudeSessionMeta returns undefined off Claude runtimes and is only invoked for daemon-managed sessions

Validation

• test/acp-config.test.ts: new dedicated assertion + the shared cc expectation helper now pins disallowedTools on every claudeSessionMeta shape (78 tests pass across acp-config + acp-host)
• daemon typecheck clean

Open question for reviewers

Whether Claude Code's own subagent machinery (Task tool) tolerates a disallowed SendMessage — #998 flags this as the confidence gap. The SDK treats disallowedTools as a top-level tool filter, and AgentConnect sessions never legitimately use agent-teams messaging, but a real-model smoke run on a delegation flow would confirm.

Fixes #998. Refs #800, #984, #905.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[agentconnect-md-test]

Small, well-scoped fix. Verified true diff against merge-base (7d2f43b), since PR head predates the Windows-CI commit b0b80cbd that GitHub lists as base — the naive base..head diff misleadingly shows Windows-fix reverts, but those aren't part of this PR's actual changes.

Real diff touches 3 files: claude-runtime.ts (new CLAUDE_DISALLOWED_BUILTIN_TOOLS const), acp-host.ts (wires it unconditionally into claudeSessionMeta's options.disallowedTools, doc comment updated), acp-config.test.ts (new dedicated test + shared cc() helper updated).

• Single call site covers both session/new and session/load — no duplication risk.
• No other location in the daemon sets disallowedTools, so no override/merge conflict.
• Test coverage matches implementation exactly.

No blocking issues.

_{sent by review-bot-fast (Claude Agent · sonnet) · open in session}

[agentconnect-md-test]

Approved. The change is correctly gated through the existing Claude-runtime predicate and the shared claudeSessionMeta() builder, so both session/new and session/load carry the deny while non-Claude session metadata remains unchanged. The pinned claude-agent-acp 0.70.0 contract explicitly merges _meta.claudeCode.options.disallowedTools into its SDK query options (adapter source), and Claude’s tool rules treat a bare SendMessage entry as removal of that exact built-in while MCP tools retain their qualified mcp__<server>__<tool> names (custom-tools documentation). The regression expectations cover the default and every existing Claude metadata shape. No blocking findings.

Validation: trusted merge parents verified; git diff --check passed; a direct Node import/assertion of the exported deny list passed. The focused Vitest run could not start in this isolated checkout because dependencies were absent and the restricted runner blocked Corepack’s network download, so that is an environment verification gap rather than a code failure. A real-model delegation smoke remains a worthwhile follow-up because current Claude docs also describe SendMessage as capable of resuming a subagent, but I would not gate this focused misdelivery fix on that broader behavior check.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}