SendMessage (cross-session messaging) disabled in Desktop app's Code tab, works fine from terminal — same account, same version

Summary

SendMessage (cross-session messaging) works from a terminal-hosted claude CLI session but is completely unavailable — Error: No such tool available: SendMessage. SendMessage is disabled for this session, in subagents as well as here. — from a session running in the Claude Desktop app's Code tab, on the same machine, same account, same Claude Code version. This broke sometime between an auto-update from 2.1.260 → 2.1.266 today; the last confirmed-working SendMessage call in this same conversation was on 2.1.260 (or earlier), several days before the update.

Environment

• Claude Code version: 2.1.266 (both surfaces)
• Previous working version: 2.1.260 (installed 2026-09-04), last confirmed SendMessage success on this version at 2026-09-07T21:46:41Z
• Auto-update to 2.1.266 landed: 2026-09-09T10:19:33Z (~/.claude/.last-update-result.json: "version_from":"2.1.260","version_to":"2.1.266","outcome":"success")
• OS: macOS
• Login: Claude Max account (org-affiliated)
• Two surfaces compared, same machine, same account, same version (2.1.266):
• Terminal-hosted claude CLI session (claude --resume, or a fresh claude launch in a terminal) — SendMessage/ListAgents work correctly, confirmed peer-to-peer delivery
• Claude Desktop app, Code tab — SendMessage throws the tool-unavailable error above; /status also returns "isn't a recognized command here. Some commands only work in the Claude Code terminal."

Repro steps

1. Open a conversation in the Claude Desktop app's Code tab.
2. Have another local claude CLI session running (peer discoverable via ListAgents).
3. Attempt SendMessage to that peer from the Desktop Code tab session.
4. Observe: Error: No such tool available: SendMessage. SendMessage is disabled for this session, in subagents as well as here.
5. Resume the exact same conversation in a terminal (claude --resume, pick the same session): SendMessage now works, no config or environment change made.

Diagnostics already ruled out

• Not a missing env var: CLAUDE_CODE_MESSAGING_SOCKET and CLAUDE_CODE_MESSAGING_TOKEN are both present in the Desktop Code tab session's environment.
• Not a version mismatch: both surfaces report 2.1.266.
• Not a settings.json deny: checked ~/.claude/settings.json, project .claude/settings.json and .claude/settings.local.json — none reference SendMessage, crossSessionInbound, or isolatePeerMachines. /status (run from the terminal side) shows setting sources as "User settings, Project local settings" only — no managed/org policy source listed.
• Not peer-specific: tested against multiple different peer sessions (including brand-new ones just started), all unreachable from the Desktop Code tab side; the same peers are reachable fine once the conversation is resumed in a terminal.
• Not fixed by restarting the Desktop session: closed and reopened the Desktop app conversation entirely (fresh session ID each time) — SendMessage still absent.

Expected behavior

Either SendMessage should work consistently across both surfaces (as it apparently did before the 2.1.260→2.1.266 update, per successful calls logged in the same conversation's transcript on 2026-09-07), or — if this is an intentional restriction for the Desktop app's Code tab surface — the error message and documentation should say so explicitly rather than presenting as a generic "disabled for this session" error indistinguishable from a bug, and the --resume-in-terminal workaround should be discoverable without needing to reverse-engineer it via diagnostics.

Additional note

If this is intentional (e.g., a deliberate new restriction on child/subagent-hosted sessions, since the error text says "in subagents as well as here"), it's a workflow regression for anyone who relies on cross-session dispatch (CTO/senior-engineer style multi-session workflows) from the Desktop app specifically — surfacing it clearly (in-app messaging, docs) would save significant debugging time, as it did here.