claude --remote silently falls back to local execution in print mode

Summary

When claude --remote is invoked in any context that triggers print mode (-p explicitly, or stdin piped / non-TTY stdout), the --remote flag is silently ignored and the session runs locally instead of spawning a cloud worker. There is no warning or error — the only tell is the absence of the usual Created remote session: ... line.

Repro

# Spawns a cloud worker as expected (interactive TTY)
claude -d --remote "hi"
# → Created remote session: General coding session
#   View: https://claude.ai/code/session_...

# Silently runs locally — no cloud worker created
echo "hi" | claude --remote
claude --remote -p "hi"
claude --remote "hi" > out.txt    # stdout not a TTY

In all the second-group cases, the prompt is answered by a local session. No Created remote session line is emitted, nothing appears at claude.ai/code, and any Bash tool calls execute against the local machine.

Why this matters

The natural use case for --remote from a script (cron, CI, wrapper, nested invocation) is exactly the case that silently breaks. A script author who writes echo "$prompt" | claude --remote reasonably expects a cloud worker to be spawned; instead the workload runs on whatever host the script happens to be executing on. That's a footgun in general and a potential security/credential-scope surprise specifically (local gh / SSH / env credentials may differ from the cloud worker's environment).

Suggested fix (any of)

1. Error: print --remote is incompatible with --print / non-TTY stdin and exit non-zero.
2. Warn + fall back: emit a stderr warning like warning: --remote ignored in print mode, running locally so the silent divergence is at least visible.
3. Honor --remote: spawn the cloud session and stream its output to stdout — probably what most users assume in scripted contexts.

(3) is the most useful long-term but (1) or (2) would at least eliminate the silent-fallback footgun.

Environment

• Claude Code: 2.1.118
• macOS: 26.4.1 (arm64)