Routines: explicit allowed_tools in session_context causes every run to fail at startup with a generic error

Environment

Claude Code routines (research preview), created/managed via the /v1/code/triggers API. Cloud sessions on anthropic_cloud environments. Observed 2026-08-02.

Summary

If a routine's job_config.ccr.session_context includes an explicit allowed_tools array, every fired session dies at startup; the run page shows only the generic banner "An error occurred while executing Claude Code." Omitting allowed_tools (letting the server fill preset:default + the standard tool list) makes the identical routine work.

Reproduction

1. Create a routine via POST /v1/code/triggers with session_context.allowed_tools: ["Bash","Read","Write","Edit","Glob","Grep","WebSearch","WebFetch"], a git source, and any prompt.
2. Fire it (schedule or /run). Session fails immediately, generic error, no artifacts.
3. Update the routine to omit allowed_tools entirely (server auto-fills ["preset:default","Task","Bash",...]). Same prompt, same environment, same repo → session runs to completion.

Isolated across two different environments (3 failed sessions with explicit list, then success with the preset on the same config):

• Failed: cse_01TDvzEHzUv6ffjpuebJ8teq, cse_01RrWhfFPj7VpQ6Z1LU9PUsE, cse_01UxfuSuk5AHw8oZTQAcoekj
• Succeeded after removing the field: cse_011WLTsu1eSwyvuJyvHcGPcs

Expected

One of: (a) validation error at create/update time if the field is unsupported for routines; (b) the explicit list merged with, or applied on top of, the required preset; or (c) documentation that allowed_tools must be omitted for routines (the routines docs currently describe "no permission-mode picker" but don't warn that supplying the field is fatal).

Impact

The failure is silent and generic, so users burn hours bisecting (env, repo access, prompt) before finding the field. A create-time 400 would have surfaced it instantly.