[Bug] CCR routines: 3 structural observability gaps — RemoteTrigger.run HTTP 400 + unmerged claude/* fire artifacts + MCP-permission-prompt deadlocks

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
Three structural observability gaps in CCR autonomous routine fires, surfaced today (2026-05-31) by a single-day observability audit of an 8-routine production audit-fleet (account dman1809):

H-1: RemoteTrigger.run MCP action returns HTTP 400 (originally reported in #54757; closed as not-planned). Still broken.
H-2 (NEW): CCR autonomous fires land on auto-generated claude/<adjective>-<word>-<NUR6q> feature branches that require manual operator-merge to be visible on main. Without merge, the audit artifacts are stranded on the feature branch — invisible to subsequent routine fires + the audit-fleet's own observation infrastructure (R_META). Routines like R_META that read only main are STRUCTURALLY BLIND to fires that landed on unmerged feature branches.
H-3 (NEW): MCP permission prompts deadlock autonomous routine fires. When a CCR routine invokes an MCP tool that requires per-session permission grant ("Allow Claude to use X tool? Deny / Always allow / Allow once"), the fire stalls indefinitely in "Running" state because no human is present to grant. No timeout. No escalation. No operator notification.

All three findings combined mean: CCR autonomous fires can succeed at cron-trigger time and still be effectively invisible to operator + downstream routines.

What Should Happen?

Evidence — fresh as of 2026-05-31
H-1 (RemoteTrigger.run HTTP 400) — re-file of #54757
Original bug body from #54757 preserved verbatim:
RemoteTrigger.run MCP action injects trigger_id into the request body. The API for POST /v1/code/triggers/{trigger_id}/run expects trigger_id in the URL path; body parameters trigger a strict-validator rejection. Three invocation patterns all fail (full request-ID captures in #54757). The local MCP tool validator also rejects calls that omit trigger_id from the request, creating a no-win situation.
Closed-as-duplicate trail (4 prior issues): #53581, #54256, #54757 (my filing), #55226. All closed by bot triage without engineering review. Re-filing per closure-bot's "Please open a new issue if this is still relevant" instruction.
H-2 (unmerged claude/* fire artifacts) — NEW
Today's observability audit on account dman1809 discovered that R5_OPENCLAW_AUDIT actually fired ≥2× via CCR autonomous mode (2026-05-28 + 2026-05-30) BUT R_META — the daily boundary-scan routine on the same account — reports R5 as "registered but not yet fired."
Root cause: both R5 fires landed on auto-generated claude/* feature branches that were never merged:

claude/wonderful-feynman-NUR6q (R5 2026-05-28 fire artifacts; +378 lines on Claude-Code repo)
claude/wonderful-feynman-QQvOr (R5 2026-05-30 fire artifacts; +516 lines on Claude-Code repo)

Both branches were pushed to origin by CCR but never auto-PR'd or auto-merged. R_META reads only origin/main, so it cannot see the fire artifacts. The fire artifacts include the routine's audit report, ESCALATIONS file, RUN_LEDGER append, and per-source code fixes — all stranded.
Contrast: R4_TRADINGBOT_AUDIT (same audit-fleet, similar architecture) DID get its fire-artifacts merged to main (e.g., commit 2c80b287), so R_META can see those fires. The merge step is operator-manual; CCR doesn't auto-merge claude/* branches.
Verified via: observability audit commit c0f216e on dman1809/Claude-Code — the audit report enumerates the stranded branches with concrete commit SHAs.
H-3 (MCP permission-prompt deadlock) — NEW
R1_MARKET_REGIME_DAILY has fired on schedule every weekday but shows a 19-weekday miss streak per R_META + ZERO completed runs in audit-fleet artifacts. Web UI click-into the 2026-05-28 + 2026-05-29 scheduled fires shows them BOTH stalled in "Running" state on an MCP permission prompt:
Allow Claude to use polygon stocks market status (atlas-datafeeds)?
Project (local)
[Deny] [Always allow] [Allow once]
The fires were correctly cron-triggered. The routine started Phase 0. The routine attempted to call an MCP tool. The MCP surface required per-session permission grant. No human was present. The fire stalled indefinitely as "Running."
No timeout. No escalation. No operator notification. The web UI run list shows the fires as scheduled — only clicking into each individual run reveals they're permission-stalled.
This is a CCR architecture issue affecting any autonomous routine that uses MCP tools. Workarounds require operator to pre-authorize MCP tools at session level OR replace MCP-tool-call paths with pre-authorized alternatives.
Asks

Fix H-1 per the suggested fix in closed #54757 (mirror RemoteTrigger.get / RemoteTrigger.update URL-path substitution into the run action). Reopen or absorb.
Provide a path for H-2: either (a) CCR auto-merges claude/* branches when the fire completes cleanly, OR (b) routine config has a "merge-to-main on success" option, OR (c) R_META-class observability tools can see across feature branches.
Fix H-3: CCR autonomous fires need a path for pre-granted MCP permissions OR a timeout-on-permission-prompt with escalation. Currently no path to either.

I'm happy to provide:

Specific commit SHAs for the H-2 stranded branches
Request IDs for the H-1 attempts (from #54757)
Screenshots of the H-3 permission prompt blocking R1
Audit-fleet documentation showing the operational impact

This is bigger than the original #54757 narrow MCP-action bug. The CCR architecture has structural observability gaps that compound silently. An 8-routine production fleet is the smallest scale at which all three become visible — smaller users may not have noticed yet.

Error Messages/Logs

Steps to Reproduce

Combined operational impact (P0 / Critical)
For my account dman1809 (account_uuid e3e96075-1623-454a-9644-cd77153b311b), this is a trinity of silent failures stacking on the 8-routine audit-fleet:

R_META_BOUNDARY_SCAN: 30 consecutive daily fires (healthy; reading main only — affected by H-2)
R1_MARKET_REGIME_DAILY: 19-weekday miss streak — root cause is H-3 (MCP permission deadlock), not cron failure
R2_PATENT_GUARDRAIL_AUDIT: 5/5 Fridays healthy — confirmed clean (only routine fully observable end-to-end)
R3_INFRA_HEALTH_WEEKLY: zero production fires ever; first Monday fire due 2026-06-01 (natural experiment scheduled)
R4_TRADINGBOT_AUDIT v1.3.1: paused; manual fires worked; auto-merge worked (precedent for "clean path")
R5_OPENCLAW_AUDIT v1.1.1: paused; manual fires worked but ARTIFACTS STRANDED on unmerged claude/* branches (H-2)

The trinity:

H-1 blocks programmatic firing (workaround: web UI manual click)
H-2 blocks observability of artifacts (workaround: operator merges each claude/* branch manually)
H-3 blocks autonomous fires from completing (workaround: pre-grant MCP permissions per session)

A working audit-fleet design requires all three to be addressable. The current workarounds compound to ~5-10 minutes of operator manual work per routine fire.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Unkown

Claude Code Version

2.1.119+

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_