[BUG] remote-control blocks on the interactive spawn-mode prompt when stdin is not a TTY: the process stays alive but never serves a session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

claude remote-control blocks on an interactive spawn-mode prompt the
first time it runs in a directory. In an unattended setup (watchdog,
autostart, service) the process starts, stays alive and looks healthy, but
never connects — no session is ever served.

Piping y into stdin does not answer this prompt. That is easy to get
wrong, because y IS the answer to the older "Enable Remote Control?"
prompt, so an existing automation that used to work silently degrades into
a running-but-dead server.

The prompt:

Spawn mode for this project:
[1] same-dir — sessions share the current directory (default)
[2] worktree — each session gets an isolated git worktree

This can be changed later or explicitly set with --spawn=same-dir or --spawn=worktree.

Choose [1/2] (default: 1):

Passing --spawn=same-dir explicitly avoids it. But remote-control --help
does not mention that the flag is required for non-interactive use, and the
prompt itself claims a default that is never applied when stdin is not a
terminal.

What Should Happen?

With a non-interactive stdin the server should apply the documented
default (same-dir) and start serving, instead of waiting forever for input
that cannot arrive.

Alternatively: exit with a clear error ("spawn mode required in
non-interactive mode, pass --spawn=same-dir") so that a watchdog sees a
failure instead of a healthy-looking process.

Error Messages/Logs

Started via PowerShell Start-Process with stdout/stderr redirected to files
(no TTY), working directory = a git repository:

  claude remote-control --permission-mode bypassPermissions

stdout after 8 seconds, process still alive, nothing further ever written:

Remote Control is launching in spawn mode, which lets you start new sessions in this project from claude.ai/code or the Claude mobile app.

Spawn mode for this project:
  [1] same-dir — sessions share the current directory (default)
  [2] worktree — each session gets an isolated git worktree

This can be changed later or explicitly set with --spawn=same-dir or --spawn=worktree.

Choose [1/2] (default: 1):

Same invocation with --spawn=same-dir connects normally within ~10 seconds:

·✔︎· Connected · <Repo> · main
    Capacity: 1/32 · New sessions will be created in the current directory

Steps to Reproduce

1. Pick a directory that has never run remote-control before.
2. Start the server without a terminal attached, e.g. on Windows:

Start-Process -FilePath 'claude.exe'
-ArgumentList 'remote-control','--permission-mode','bypassPermissions'
-WorkingDirectory '<some-git-repo>'
-WindowStyle Hidden
-RedirectStandardOutput 'out.log' -RedirectStandardError 'err.log'

1. Wait 30 seconds. The process is alive; out.log ends at

"Choose [1/2] (default: 1):" and the device never appears as connected
in the mobile app.

1. Piping 'y' into stdin does not change this.
2. Repeat with --spawn=same-dir added: connects normally.

Environment: Windows 11 Pro 26200, Claude Code 2.1.227 native build.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.227 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

Context: the server is started by a watchdog loop (PowerShell, launched
from the Windows startup folder) so that remote sessions are available
whenever the machine is on. That is exactly the scenario where this bites:
nothing is watching the process output, the process is alive, and the
device simply never shows up as connected.

Note for reproduction: piping "y" into stdin does NOT answer this prompt.
That matters because "y" is the correct answer to the older
"Enable Remote Control? (y/n)" prompt, so an automation written against
the previous behaviour silently degrades into a running-but-dead server
rather than failing loudly.