claude-code - 💡(How to fix) Fix [BUG] Regression: Bypass Permissions mode blocks MCP tools with requiresUserInteraction flag [1 participants]

**Error message returned by the harness when calling the tool in Bypass Permissions mode:**


This tool requires user interaction and is unavailable in unsupervised mode.


**Tool calls that triggered it (all in the same TTY session, Bypass Permissions active):**


mcp__scheduled-tasks__update_scheduled_task
  taskId: sage-ziele-session
  cronExpression: 0 */7 * * *
→ Error: This tool requires user interaction and is unavailable in unsupervised mode.

mcp__scheduled-tasks__update_scheduled_task
  taskId: sage-dreaming
  cronExpression: 13 */7 * * *
→ Error: This tool requires user interaction and is unavailable in unsupervised mode.


**Same calls succeeded earlier in the same session** without any settings or mode change in between — suggests state-dependent gating, not a static rule. After app restart the block persisted.

**Resolution:** Switching to Ask Permissions mode and accepting the prompt with "Always allow" let the same tool calls go through. Switching back was not retested.

**Settings at time of failure (`~/.claude/settings.json` and project `.claude/settings.local.json`):**


{ "autoMemoryEnabled": false }


No `permissions`, no `autoMode`, no hooks — i.e. nothing user-configured that would explain the block. The block originates from harness defaults.

---

1. Open Claude Code in an interactive terminal session.
2. Enable Bypass Permissions (press Shift+Tab until the footer shows "bypass permissions").
3. Invoke an MCP tool annotated `requiresUserInteraction`. Reliable example:

   mcp__scheduled-tasks__update_scheduled_task
     taskId:         <any existing scheduled task ID from mcp__scheduled-tasks__list_scheduled_tasks>
     cronExpression: 0 */7 * * *

4. Observe the response:

   "This tool requires user interaction and is unavailable in unsupervised mode."

5. Without changing any settings, switch the permission mode to Ask Permissions (Shift+Tab).
6. Invoke the exact same tool call again. A confirmation prompt appears; click "Always allow".
7. The call now succeeds. Subsequent calls of the same tool also succeed — even after switching back to Bypass Permissions, in some cases.

Expected at step 4: the call succeeds, because Bypass Permissions is the user's blanket "yes" to all tool calls.
Actual at step 4: the call is hard-blocked with the message above.

---

Context that may help triage:

- The block is not static. Within the same TTY session, the same tool (`mcp__scheduled-tasks__update_scheduled_task`) succeeded several times in a row, then began failing for the rest of the session with the "unsupervised mode" error — without any settings change, mode switch, or restart in between. This suggests the gate is driven by accumulated session state (turn count, parallel tool calls, prior error reminders, or similar), not by a static rule.

- App restart did not clear the block. A fresh session in the same install reproduced the failure on the first attempt.

- Bypass Permissions did not skip the block. The documented purpose of Bypass Permissions is to suppress all permission prompts, yet `requiresUserInteraction` MCP tools are blocked rather than passed through.

- Switching to Ask Permissions + clicking "Always allow" once was the only working remedy. After that, calls succeed.

- The wording "unavailable in unsupervised mode" is misleading. A human is at the keyboard, in an interactive TTY, actively choosing the mode — the session is supervised by any normal definition. Whatever flag the harness is checking, it is not "is this session supervised."

- Affected MCP server is the built-in `scheduled-tasks` server. Likely affects any MCP tool carrying the `requiresUserInteraction` annotation, but only `scheduled-tasks` was tested.

- No user-side configuration that could explain the block. Both `~/.claude/settings.json` and project `.claude/settings.local.json` contained only `{ "autoMemoryEnabled": false }` at the time of failure. No `permissions`, no `autoMode`, no hooks.

- Same workflow worked in the version installed the previous day. The behavior change is therefore a regression introduced by an update between then and the day the report was filed.

Suggested investigation paths:
  1. Identify which harness gate emits "This tool requires user interaction and is unavailable in unsupervised mode" — it does not appear in the public auto-mode classifier documentation.
  2. Check why Bypass Permissions mode does not short-circuit that gate the way it short-circuits the regular permission prompt.
  3. Reproduce the session-state-dependent flip from "allowed" to "blocked" mid-session.