[BUG] Fired Claude Code Remote / Routine sessions hang indefinitely on ANY external call, including non-MCP tools (web_fetch) — not limited to MCP connector approval-gating

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 Claude Code Remote scheduled task ("Routine"), when fired — either on its cron schedule or via a manual run — hangs indefinitely with no error, no timeout, and no way to detect or route around the stall from outside the session.

Originally isolated to Gmail/Drive MCP connector calls (2026-07-18). As of 2026-07-19, reproduced on web_fetch (a built-in tool, not an MCP connector) and on a different MCP server (a personal device-bridge connector) in the same isolated test — ruling out MCP-connector-approval-gating as the sole explanation. This looks related to #61015 / #61027 / #61097 / #61143 (same symptom family: fired routines failing to complete external calls) but with a silent, zero-output hang rather than a visible "MCP tool call requires approval" error, and it reproduces on a non-MCP tool call. Filing separately because #61015 is now closed as completed, and our repro suggests that fix did not address the full scope of the underlying issue. (Note: #61044/#61190 tracked a similar-sounding but distinct May 2026 regression that was fixed and locked on 2026-05-21 -- this report is a fresh, July repro with a different symptom, filed after confirming #61190 is locked and #61015 is closed.)

What Should Happen?

Either the external call completes (returning results or an error) within a reasonable time, or it fails/times out with a surfaced error, allowing the session to proceed or at least terminate visibly. A fired Routine should never hang indefinitely with zero output and no way for the user (or the model itself) to detect or diagnose the stall.

Error Messages/Logs

None. That's the core of the bug: no error, no stack trace, no timeout message of any kind is ever surfaced, from either the fired session itself or from a separate session inspecting it afterward. The only observable signal is last_fired_at confirming the trigger started, and the permanent absence of whatever output the trigger was supposed to produce.

Steps to Reproduce

1. Create a trigger (scheduled Routine) whose prompt does exactly two things, in order: (a) call web_fetch on a known-good, independently-verified URL (we used our own deployed Google Apps Script Web App, curl-verified working seconds before the test), (b) immediately after, report the result via a tool that shares no code path with (a) -- we used a personal device-bridge MCP server's shell-exec tool to append one line to a file.
2. Fire the trigger manually, or let it fire on its schedule.
3. Confirm the trigger genuinely fired (last_fired_at populated).
4. Wait and check whether step (b)'s output ever appears.

Actual result: step (b)'s output never appears. Checked at roughly 2, 5, and 10 minutes post-fire -- zero file activity. No error, no timeout, no partial output of any kind.

We first isolated this to Gmail/Drive MCP connector calls on 2026-07-18 (steps to reproduce: fire a trigger that calls a Gmail or Drive connector tool, then a guaranteed-safe fallback write; the fallback never executes). The web_fetch repro above (2026-07-19) is the more isolated, more recent test, and is the one that rules out MCP-connector-approval-gating as the sole explanation, since web_fetch is not an MCP connector at all.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A -- not a CLI version regression. Last known-good state was earlier the same day (2026-07-18, ~01:48 UTC) using the identical trigger config that later hung.

Claude Code Version

N/A -- this report is about the claude.ai scheduled Routines / Claude Code Remote server-side execution surface, not the local Claude Code CLI.

Platform

Other

Operating System

Other

Terminal/Shell

Non-interactive/CI environment

Additional Information

We have a detailed, timestamped repro log spanning 2026-07-18 to 2026-07-19 (multiple independent trigger IDs, control tests, an isolated diagnostic, and cross-checks against a working attended-session baseline). Happy to share the full write-up if useful for triage.

Environment note: connectors observed affected include Gmail, Google Calendar, Google Tasks, and Google Drive (all native/OAuth), plus a third-party device-bridge MCP server -- and, most importantly, web_fetch, which is not an MCP connector at all.