Scheduled routine (CCR) fails with generic "An error occurred while executing Claude Code" even for trivial MCP-free tasks

Summary

A scheduled routine (created via the RemoteTrigger/schedule API, CCR job type) consistently fails with the generic error:

An error occurred while executing Claude Code. You can try again by sending a new message or starting a new session.

This happens even when the task is reduced to the bare minimum — no MCP tool calls, no large data, just a couple of shell commands and a git push. No further detail is surfaced anywhere I could find (the routine's page in the UI shows only this same generic message).

Setup

• Routine created via RemoteTrigger action: "create" with job_config.ccr pointing at a git repo (sources: [{git_repository: {url: ...}}]), environment_id = the default environment, model claude-sonnet-5, allowed_tools: ["Bash","Read","Write","Edit","Glob","Grep"].
• Two MCP connectors attached initially (Google Drive, Google Cloud BigQuery), later removed for isolation testing (clear_mcp_connections: true).
• Triggered manually via RemoteTrigger action: "run" (not on the cron schedule) for each test below.

Reproduction steps / escalating isolation

I ran 5 attempts total, updating the routine's prompt between each one to isolate the cause. All 5 failed identically with the same generic error, each after a real wait (I polled GitHub for the expected resulting commit for 8–22 minutes before concluding failure):

1. Full task: search a Google Drive file, download a ~4.6MB spreadsheet as xlsx (base64 response, ~6.2M characters), run a local Python script, commit + push to main. → Failed.
2. Same as #1, but with an explicit instruction telling the agent never to Read/cat/echo the large downloaded file's raw content, and instead decode it entirely inside one Python script invocation (in case the agent was pulling a multi-MB tool result into its own context/response). → Failed identically.
3. Minimal task: search_files + get_file_metadata (small, no content) + one small execute_sql_readonly BigQuery query (SELECT COUNT(*) ...) + write a one-line file + git commit && git push. No large downloads at all. → Failed identically.
4. MCP-free task: clear_mcp_connections: true, task is just pwd, git remote -v, write a one-line file, git commit && git push. → Failed identically.
5. Same as #4, re-run after connecting to a corporate VPN (to rule out any network-path dependency — this repo's deployed app happens to be IP-restricted to a VPN, though the routine itself runs in Anthropic's cloud and shouldn't care about the user's local network at all). → Failed identically.

In every case:

• last_fired_at on the trigger updates (confirming the routine did start).
• No new commit ever appears on main (confirmed via gh api repos/.../commits/main).
• No new branch or PR appears either.
• The routine's page shows only the generic "An error occurred..." message with no stack trace, failed tool name, or step indicator.

Expected behavior

Either:

• The routine succeeds (even the MCP-free, git-only case in step 4 should be nearly impossible to fail if the environment/session is healthy), or
• If something goes wrong, the failure should be attributable — an error message identifying which step/tool/API call failed, visible either in the chat transcript or the routine's run history — so the task's prompt can actually be debugged instead of guessed at.

Notes

• Manually running the equivalent multi-step pipeline (same Drive/BigQuery MCP calls, same large xlsx download+decode, same git commit/push) in an interactive Claude Code session (not a scheduled routine) worked without issue in the same account, same repo, same day — including the large file download, which is gracefully redirected to a saved tool-result file with a helpful message when it exceeds the inline token limit. This suggests the scheduled-routine (CCR) execution path may behave differently from interactive sessions in a way that's currently invisible to the end user.
• Happy to share the exact trigger/job_config JSON or trigger ID via a private channel if useful for reproducing internally.