Scheduled/triggered sessions on “bridge” environments silently no-op — fire per the API, produce zero observable effect

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?

Summary:
Claude Code scheduled routines (RemoteTrigger / /schedule) running on “bridge”-type environments (a persistent connection to a real, always-on personal machine via claude remote-control, as opposed to an ephemeral cloud sandbox) intermittently fire per the API — last_fired_at updates correctly, ended_reason is empty, no error is reported — but the session inside produces no observable effect whatsoever: no file writes, no log lines, not even a single unconditional first instruction executing. This happens both on cron-scheduled fires and on manually-invoked RemoteTrigger action:"run" calls, so it isn’t specific to the scheduling mechanism itself.

What rules this out as something else:

• Not resource exhaustion: reproduced on a freshly-restarted, verified-healthy bridge (low process count, low memory/swap).
• Not hardware failure: full diagnostic on the host machine (SMART disk health, kernel logs, OOM history, thermal, systemd unit failures) came back completely clean.
• Not a corrupted/stale trigger: reproduced identically on a brand-new trigger created from scratch, whose very first instruction was an unconditional “write one log line before doing anything else” — about as close to a trivial smoke test as possible. Same silent no-op.
• Not specific to one routine: reproduced independently on two structurally different routines (a heartbeat/maintenance routine and a separate job-queue processor) across multiple trigger IDs and multiple machines in the same fleet.

What does work, ruling out “bridge environments can’t execute at all”:
A live, interactively-driven session on the same type of bridge environment executes reliably every time — SSH commands, file writes, everything — including throughout the same diagnostic session where the triggered sessions failed. The failure appears specific to unattended, autonomously-dispatched execution (scheduled or manually triggered via the API) on a bridge environment, not to bridge environments or real-hardware execution in general.

Impact: Any unattended automation built on scheduled triggers pointed at a bridge environment cannot be trusted to actually run — it fails silently, with no error surfaced anywhere the session owner can see, making it very hard to detect without independently verifying side effects (e.g., SSHing into the target machine directly to check file state, as we had to do here).

Ask: Backend visibility into what these triggered sessions actually attempt when dispatched to a bridge environment — this isn’t diagnosable further from inside a session, since every externally-observable signal (API response, file state, logs, resource health) has already been checked and ruled out.

What Should Happen?

See above

Error Messages/Logs

See above

Steps to Reproduce

See description

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

None

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

See description