claude-code - 💡(How to fix) Fix /remote-control regressed: now blocked in Claude Desktop's local-agent (non-interactive) session

Summary

/remote-control worked for several days when typed inside the Claude Desktop app's agent session, then suddenly stopped after the desktop app updated its bundled Claude Code to 2.1.156 (bundle dated May 28). It now returns:

/remote-control isn't available in this environment.

This appears to be an undocumented regression — the CHANGELOG has no entry about adding remote-control to the non-interactive command denylist.

Environment

• Claude Desktop app, version 1.9659.2
• Bundled Claude Code: 2.1.156 (~/Library/Application Support/Claude/claude-code/2.1.156/, bundle mtime May 28 22:54)
• Entrypoint: CLAUDE_CODE_ENTRYPOINT=claude-desktop, CLAUDE_AGENT_SDK_VERSION=0.3.156
• Session is non-interactive (--output-format stream-json, no TTY)
• macOS (Apple Silicon)
• Auth: claude.ai (Max), no ANTHROPIC_API_KEY set

Root cause

The command is rejected by a non-interactive denylist. In the 2.1.156 binary:

if (options.isNonInteractiveSession && DENYLIST.has(cmd)) {
  return `/${cmd} isn't available in this environment`;
}

where the denylist is:

new Set(["list","scheduled","assistant","remote-control","hub"])

remote-control is now a member of this set, so it is blocked in the desktop app's non-interactive session. This is distinct from the separate cmd_local_jsx_headless / "opens an interactive panel … Run it from the Claude Code terminal instead" gate.

Confirmation it's version-bound

• The same denylist (including remote-control) is present in 2.1.158 as well, so it was introduced at or before 2.1.156 and persists in newer releases.
• No CHANGELOG entry references adding remote-control to a non-interactive/headless denylist.

Expected

/remote-control should remain usable from the Claude Desktop app session as it was before the May 28 update — or, if the block is intentional, it should be documented and the command should be hidden from the slash menu in that context (it currently still appears as a valid option, which is misleading).

Workaround

Run it from a real terminal: claude --remote-control (works on 2.1.158).