Remote Control sessions get the background-command time limit meant for unattended sessions

Status Open
Reported on v2.1.288
Maintainer reply None cached
Activity 0 comments · opened Oct 9, 2026

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?

A Remote Control session gets the background-command time limit that 2.1.288 scoped to unattended sessions ("Changed the background command time limit to apply only in unattended sessions (-p, Agent SDK, CI, cloud); terminal, desktop app and VS Code sessions have no limit"). A session I start from the iOS app or claude.ai/code on my laptop's claude remote-control environment is one I'm driving, the same as a terminal session, yet its background commands are stopped at 30 minutes, or at the call's timeout (at most 2 hours), with "was stopped after reaching its background time limit". The same command in a terminal session on the same machine runs until it exits.

The bridge runs each session as claude --print --sdk-url … --input-format stream-json --output-format stream-json …, and the gate, as I read it in the 2.1.292–2.1.295 binaries, is: not interactive, and not a desktop-app or VS Code host, and tengu_cosmic_shore. --print makes the worker non-interactive and nothing exempts a bridge child, so it lands on the unattended side. The session's own Bash tool schema says so: its run_in_background description reads "With it, timeout limits how long the command may run in the background before it is stopped (default 1800000 ms, max 7200000 ms)".

BASH_DEFAULT_TIMEOUT_MS raises the limit, but it is also the foreground default, so it can't lift the background limit without changing foreground behaviour and the tool description with it.

What Should Happen?

A session the Remote Control bridge spawns has no background-command time limit, like terminal, desktop app and VS Code sessions: a background command runs until it exits or is stopped.

Error Messages/Logs

A Remote Control session created from claude.ai/code on 2026-10-09 (worker 2.1.292), asked to run sleep 20; echo done with run_in_background: true and timeout: 5000; the notification it received:

<status>killed</status>
<summary>Background command "probe" was stopped after reaching its background time limit</summary>

In a headless run of the same shape, the debug log line for that stop:

LocalShellTask bvs5tf8n2: stopped at its 5000ms background deadline

Steps to Reproduce

  1. Run claude remote-control on a machine.
  2. From claude.ai/code or the mobile app, start a session in that environment and ask it to run sleep 20; echo done with run_in_background: true and timeout: 5000.
  3. It is stopped after 5 s with the notice above.
  4. Ask a terminal session on the same machine to make the same call: the timeout is ignored and the command prints done.

Without a timeout, the default limit stops it at 30 minutes.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.284

Claude Code Version

2.1.295 (Claude Code); the bridge's workers run 2.1.292

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Arch Linux, the bridge running as a systemd user unit. The bridge already marks its children: the worker's environment carries CLAUDE_CODE_ENVIRONMENT_KIND=bridge.

View original on GitHub ↗