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).
Summary
/remote-controlworked 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:This appears to be an undocumented regression — the CHANGELOG has no entry about adding
remote-controlto the non-interactive command denylist.Environment
1.9659.2~/Library/Application Support/Claude/claude-code/2.1.156/, bundle mtime May 28 22:54)CLAUDE_CODE_ENTRYPOINT=claude-desktop,CLAUDE_AGENT_SDK_VERSION=0.3.156--output-format stream-json, no TTY)ANTHROPIC_API_KEYsetRoot cause
The command is rejected by a non-interactive denylist. In the 2.1.156 binary:
where the denylist is:
remote-controlis now a member of this set, so it is blocked in the desktop app's non-interactive session. This is distinct from the separatecmd_local_jsx_headless/ "opens an interactive panel … Run it from the Claude Code terminal instead" gate.Confirmation it's version-bound
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.remote-controlto a non-interactive/headless denylist.Expected
/remote-controlshould 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).