Skip to content

fix(agent): allowlist orcha MCP tools via settings too, not just --allowedTools#66

Merged
nathanwhit merged 1 commit into
mainfrom
mcp-allowlist-via-settings
Jun 25, 2026
Merged

fix(agent): allowlist orcha MCP tools via settings too, not just --allowedTools#66
nathanwhit merged 1 commit into
mainfrom
mcp-allowlist-via-settings

Conversation

@nathanwhit

Copy link
Copy Markdown
Owner

What

A claude manager wedged in prod on the interactive permission dialog for orcha - mark_objective_done (Do you want to proceed? 1. Yes / 2. Yes, don't ask again / 3. No), hanging until a human intervened.

Root cause (verified on the box)

bypassPermissions mode does not auto-approve custom MCP tools. It covers built-in tools (Bash/Edit — verified they run under bypass), but Claude deliberately requires MCP tools to be explicitly allowlisted even under bypass. So a manager's entire orcha tool surface (mcp__orcha*) is gated solely by --allowedTools=mcp__orcha. This is the asymmetry with codex, whose --dangerously-bypass-approvals-and-sandbox is a true global bypass that covers its MCP tools too.

Reproduced with a throwaway stdio MCP server on the box:

permission mode allowlist custom MCP tool
bypassPermissions none ❌ denied/prompts
bypassPermissions mcp__test (flag) ✅ runs
bypassPermissions .claude settings permissions.allow ✅ runs
default none ❌ prompts
default mcp__test (server wildcard) ✅ runs

The current code passes --allowedTools=mcp__orcha on every path (cold + --continue resume) and that approves the tool — so the wedge was a session where the flag wasn't in force (most likely a manager alive across a redeploy under an older binary). Relying on a single per-invocation flag for the only thing standing between a manager and an indefinite hang is too fragile.

Fix

Carry the allowlist through settings.permissions.allow (mirroring spec.AllowedTools) in the inline --settings that every claude launch already passes — a second, independent approval path alongside the flag. Verified on the box that settings.permissions.allow approves an MCP tool under bypassPermissions with no --allowedTools flag, on both cold launch and --continue resume.

Also applied immediately as a box mitigation for the live fleet: added permissions.allow: ["mcp__orcha"] to ~/.claude/settings.json on the agent host (bulletproof regardless of orcha binary version).

Tests

  • TestClaudeControlArgs_AllowedToolsAlsoRideSettingsPermissions — settings carries permissions.allow mirroring AllowedTools.
  • TestClaudeControlArgs_NoAllowedToolsOmitsPermissions — no permissions block when there's nothing to approve; settings stays valid JSON.
  • Existing TestClaudeControlArgs_* (allowedTools =-token, co-author byline) still pass.

https://claude.ai/code/session_018CRsfX79dM42QC2BrW1vtZ

…lowedTools

bypassPermissions does NOT auto-approve custom MCP tools: Claude requires MCP tools to be explicitly allowlisted even under bypass (it covers built-ins like Bash/Edit, but not mcp__* tools). So a manager's entire orcha tool surface (mcp__orcha*) is gated SOLELY by --allowedTools. A single launch/resume edge, or a CLI version whose --allowedTools MCP-wildcard match drifts, drops the manager into per-tool permission prompts — and an interactive manager that prompts just hangs until a human intervenes (observed in prod: a manager wedged on the mark_objective_done approval dialog).

Carry the allowlist through settings.permissions.allow (mirroring AllowedTools) in the inline --settings that every claude launch already passes, giving a second, independent approval path alongside the flag. Verified on the box that settings.permissions.allow approves an MCP tool under bypassPermissions with no --allowedTools flag, on both cold launch and --continue resume.

Claude-Session: https://claude.ai/code/session_018CRsfX79dM42QC2BrW1vtZ
@nathanwhit nathanwhit merged commit 97cdcde into main Jun 25, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant