claude-code - 💡(How to fix) Fix claude --remote silently falls back to local execution in print mode [1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52542Fetched 2026-04-24 06:04:24
View on GitHub
Comments
1
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×3commented ×1

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.

Error Message

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.

  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.

Root Cause

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).

Code Example

# 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
RAW_BUFFERClick to expand / collapse

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)

extent analysis

TL;DR

To fix the issue where the --remote flag is silently ignored when claude is invoked in print mode or with non-TTY stdout, consider modifying the claude command to either error, warn, or honor the --remote flag.

Guidance

  • Verify the current behavior by running the provided repro steps and checking for the absence of the Created remote session line.
  • Consider implementing one of the suggested fixes: erroring out when --remote is used with print mode or non-TTY stdin, warning the user and falling back to local execution, or honoring the --remote flag and spawning a cloud session.
  • When choosing a fix, consider the potential security implications of silently falling back to local execution, especially in scripted contexts.

Example

No code snippet is provided as the issue does not contain sufficient information to generate a concrete example.

Notes

The suggested fixes aim to address the silent fallback issue, but the optimal solution may depend on the specific use cases and requirements of the claude command.

Recommendation

Apply a workaround, such as modifying the claude command to error out when --remote is used with print mode or non-TTY stdin, to prevent silent fallbacks and potential security issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING