[FEATURE] requiresUserInteraction MCP tools silently break Routines
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
; behavior
changed between 2026-07-30 and 2026-08-03 with no changelog entry
Two related problems found while building an unattended GitHub <-> Claude
Design sync in a Routine. I understand and agree with the design intent of
requiresUserInteraction ("The prompt has to reach a person") -- these are
about documentation and change communication, not the policy itself.
--- 1. The Routines page contradicts the MCP page ---
https://code.claude.com/docs/en/routines states:
"Routines run autonomously as full Claude Code cloud sessions: there is
no permission-mode picker and no approval prompts during a run."
This is false for MCP tools marked _meta["anthropic/requiresUserInteraction"].
In a Routine session such a tool DOES prompt, and the run stalls waiting for
a human who is by definition not there. The exception is documented on
https://code.claude.com/docs/en/mcp#require-approval-for-a-specific-tool
but nothing on the Routines page points to it.
Concrete cost: I built a multi-stage unattended sync procedure on the
promise in that sentence. It cannot ever complete unattended, and I only
learned why after several failed runs.
Request: add the exception to the Routines page, ideally with the list of
tools/annotations that force a prompt.
--- 2. Undocumented behavior change, 2026-07-30 -> 2026-08-03 ---
Identical repository configuration produced opposite behavior:
2026-07-30 (Claude Code version unknown, cloud runner)
settings.json was exactly: {"permissions":{"allow":["DesignSync"]}}
no PreToolUse hook registered
Unattended run wrote a file to a Claude Design project via
DesignSync finalize_plan + write_files with NO prompt. Run completed
through capture branch creation and a merged PR.
2026-08-03 onward (same repo, same account, same project)
DesignSync finalize_plan now raises a permission prompt in unattended
Routine sessions. Runs stall indefinitely.
The MCP page says: "The anthropic/requiresUserInteraction annotation
requires Claude Code v2.1.199 or later. Earlier versions ignore it and
apply the standard permission flow."
So the likely cause is a cloud-runner version bump that started enforcing
an annotation DesignSync already carried. That is a reasonable change, but
I could not find it in https://code.claude.com/docs/en/changelog, and from
the operator side it looked like a regression in my own code. I spent
roughly two days debugging my repository for a platform-side change.
Request: when a version bump starts enforcing an annotation that changes
whether existing unattended automation can complete, note it in the
changelog. "Now enforces anthropic/requiresUserInteraction (previously
ignored)" would have saved all of that.
--- Evidence from my own guard logs (2026-08-04) ---
My repository runs a PreToolUse hook that returned allow for both calls:
{"timestamp":"2026-08-04T16:10:00.086Z","tool":"DesignSync",
"action":"finalize_plan","decision":"allow",
"reasonCode":"CANARY_BOOTSTRAP_EXACT_GRANT_DISPATCH_RESERVED"}
{"timestamp":"2026-08-04T16:13:34.195Z","tool":"DesignSync",
"action":"write_files","decision":"allow",
"reasonCode":"CANARY_BOOTSTRAP_EXACT_GRANT_DISPATCH_RESERVED"}
finalize_plan prompted anyway (a human happened to be watching and
approved); write_files did not. This matches the documented behavior
exactly -- the annotation is on finalize_plan only. Posting it because it
confirms the hook-allow path is not the cause and may help others
diagnosing the same symptom faster.
--- What would help ---
Not asking to bypass the consent step. What I actually need is a way to
make one human approval cover a bounded, reviewed scope for an unattended
run -- e.g. an operator-signed plan scope that canUseTool or a
PermissionRequest hook may satisfy once per cycle. Today the only options
are "a human is present at an unpredictable moment mid-run" or "no
unattended writes at all."
Environment: Claude Code on the web (cloud Routine sessions),
repo hanjunjeong/claude-design, DesignSync MCP tool.
Proposed Solution
; behavior
changed between 2026-07-30 and 2026-08-03 with no changelog entry
Two related problems found while building an unattended GitHub <-> Claude
Design sync in a Routine. I understand and agree with the design intent of
requiresUserInteraction ("The prompt has to reach a person") -- these are
about documentation and change communication, not the policy itself.
--- 1. The Routines page contradicts the MCP page ---
https://code.claude.com/docs/en/routines states:
"Routines run autonomously as full Claude Code cloud sessions: there is
no permission-mode picker and no approval prompts during a run."
This is false for MCP tools marked _meta["anthropic/requiresUserInteraction"].
In a Routine session such a tool DOES prompt, and the run stalls waiting for
a human who is by definition not there. The exception is documented on
https://code.claude.com/docs/en/mcp#require-approval-for-a-specific-tool
but nothing on the Routines page points to it.
Concrete cost: I built a multi-stage unattended sync procedure on the
promise in that sentence. It cannot ever complete unattended, and I only
learned why after several failed runs.
Request: add the exception to the Routines page, ideally with the list of
tools/annotations that force a prompt.
--- 2. Undocumented behavior change, 2026-07-30 -> 2026-08-03 ---
Identical repository configuration produced opposite behavior:
2026-07-30 (Claude Code version unknown, cloud runner)
settings.json was exactly: {"permissions":{"allow":["DesignSync"]}}
no PreToolUse hook registered
Unattended run wrote a file to a Claude Design project via
DesignSync finalize_plan + write_files with NO prompt. Run completed
through capture branch creation and a merged PR.
2026-08-03 onward (same repo, same account, same project)
DesignSync finalize_plan now raises a permission prompt in unattended
Routine sessions. Runs stall indefinitely.
The MCP page says: "The anthropic/requiresUserInteraction annotation
requires Claude Code v2.1.199 or later. Earlier versions ignore it and
apply the standard permission flow."
So the likely cause is a cloud-runner version bump that started enforcing
an annotation DesignSync already carried. That is a reasonable change, but
I could not find it in https://code.claude.com/docs/en/changelog, and from
the operator side it looked like a regression in my own code. I spent
roughly two days debugging my repository for a platform-side change.
Request: when a version bump starts enforcing an annotation that changes
whether existing unattended automation can complete, note it in the
changelog. "Now enforces anthropic/requiresUserInteraction (previously
ignored)" would have saved all of that.
--- Evidence from my own guard logs (2026-08-04) ---
My repository runs a PreToolUse hook that returned allow for both calls:
{"timestamp":"2026-08-04T16:10:00.086Z","tool":"DesignSync",
"action":"finalize_plan","decision":"allow",
"reasonCode":"CANARY_BOOTSTRAP_EXACT_GRANT_DISPATCH_RESERVED"}
{"timestamp":"2026-08-04T16:13:34.195Z","tool":"DesignSync",
"action":"write_files","decision":"allow",
"reasonCode":"CANARY_BOOTSTRAP_EXACT_GRANT_DISPATCH_RESERVED"}
finalize_plan prompted anyway (a human happened to be watching and
approved); write_files did not. This matches the documented behavior
exactly -- the annotation is on finalize_plan only. Posting it because it
confirms the hook-allow path is not the cause and may help others
diagnosing the same symptom faster.
--- What would help ---
Not asking to bypass the consent step. What I actually need is a way to
make one human approval cover a bounded, reviewed scope for an unattended
run -- e.g. an operator-signed plan scope that canUseTool or a
PermissionRequest hook may satisfy once per cycle. Today the only options
are "a human is present at an unpredictable moment mid-run" or "no
unattended writes at all."
Environment: Claude Code on the web (cloud Routine sessions),
repo hanjunjeong/claude-design, DesignSync MCP tool.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
MCP server integration
Use Case Example
_No response_
Additional Context
_No response_