`claude --bg` code-writing sessions stall on permission prompts with no non-interactive way to reply (acceptEdits insufficient)

Discovered while piloting single-terminal background dispatch (claude agents / claude --bg) for real development work on Claude Code 2.1.157.

What's wrong

When dispatching a background session with claude --bg that needs to write code, the session stalls on a permission prompt even under --permission-mode acceptEdits, and there is no non-interactive way to answer it from the shell. This blocks unattended automation.

Steps to reproduce

1. claude --bg --model opus --permission-mode acceptEdits --name test "create a Foo.cs class; delegate the actual write to a c-sharp-pro subagent"
2. The dispatched (top-level) session spawns a subagent that calls Write.
3. claude agents --json shows the session status: "waiting" — blocked on a permission prompt: 1. Yes / 2. Yes, allow all edits during this session.
4. There is no claude reply <id> <choice> equivalent. claude logs is read-only; claude attach needs an interactive TTY, unavailable in headless automation.

Expected

Either acceptEdits auto-approves the subagent's Write in a background session, or a non-interactive way exists to answer a pending prompt from the shell (e.g. claude reply <id> <choice>).

Actual

Session hangs in waiting indefinitely. The only workaround is --permission-mode bypassPermissions, which itself requires a one-time interactive claude --dangerously-skip-permissions disclaimer acceptance — defeating unattended use.

Environment

• Claude Code 2.1.157
• Windows 11, Anthropic API, terminal (cross-platform relevant)

Related

#36170, #39889