[BUG] Permission approval prompts never appear in the voice/text interface

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?

What's Wrong?

When a tool or file write needs first-time approval, the approval prompt never reaches this interface. Instead of asking, the action just fails outright, with no popup or notification anywhere to click and grant it. Confirmed across five unrelated cases in one session.

What Should Happen?

Permission approval prompts should surface in the interface (popup, notification, or inline message) allowing the user to review and grant or deny permissions before tools are executed.

Error Messages/Logs

• Skill tool: "Execute skill: <skill name>" (empty error)
• Bash and PowerShell: "This command requires approval."
• Gmail MCP connector: "Claude requested permissions to use this tool, but you haven't granted it yet."
• Plain file edit: "requested permissions... haven't granted it yet"

Steps to Reproduce

1. Start a new session in the voice/text interface
2. Attempt any of the following:

• Execute a skill for the first time (e.g., dataviz or update-config)
• Run a shell command requiring approval (e.g., python3 or awk)
• Call an MCP connector tool for the first time (e.g., Gmail search_threads)
• Edit a file in an already-permitted working directory

1. Observe that the tool fails with a permission error
2. Look for an approval prompt anywhere on the interface
3. No popup, notification, or inline message appears to grant permission

Affected Tools

1. Skill tool — both the dataviz skill and the update-config skill returned an empty error
2. Bash and PowerShell — python3 and awk both errored with "This command requires approval."
3. Gmail MCP connector — search_threads failed with permission message, no prompt appeared
4. Plain file edit — local file write in already-permitted working directory failed the same way

Root Cause Analysis

Case 4 (local file edit in permitted directory) is the most telling: it rules out a scope- or connector-specific explanation. Across five different tool types — skills, shell commands, an MCP connector, and a local file edit — the common failure is identical. This points to the approval-prompt UI itself not rendering in this interface, rather than a bug in any individual tool.

Additional Information

• Reported: July 18, 2026
• Status: Still open
• This blocks multiple workflows and prevents first-time tool usage in this interface

What Should Happen?

Expected behavior

The approval prompt should actually appear so the permission can be granted, and the tool should then proceed. Right now the tool call just fails outright with no way to respond at all.

Error Messages/Logs

## Error messages and logs
Skill tool: `<error>Execute skill: dataviz</error>` — same empty error for `update-config`, no further detail given.

Bash and PowerShell: "This command requires approval"

Gmail MCP connector: "Claude requested permissions to use this tool, but you haven't granted it yet."

Local file edit inside the allowed working directory: "Claude requested permissions to write to [file path], but you haven't granted it yet."

Version check and web search (found while filing this report): same two error strings above, repeated on `claude --version` and `WebSearch`.

## Filing status
- Drafted and approved by Rachel July 18, 2026.
- First filing attempt via `gh issue create` blocked by the same bug (`gh auth status` needed approval that never surfaced).
- Still open as of July 18, 2026 — see [[Active Priorities]] for current status.

Steps to Reproduce

Steps to reproduce

1. Start a Claude Code session in a voice/text conversational interface (this was observed in the interface used for spoken conversation with Claude, not a standard terminal session).
2. Invoke any tool or action that has not yet been approved in the current session. Any of the following reproduce it:

• Call a Skill for the first time (e.g. a skill named dataviz or update-config).
• Run a shell command that requires first-time approval (e.g. python3, awk, or claude --version in Bash/PowerShell).
• Call an MCP connector tool for the first time (e.g. a Gmail connector's search_threads).
• Call WebSearch for the first time.
• Edit or write a file, even one located inside a directory the session has already been granted access to.
• Run gh auth status or gh issue create in Bash.

1. Observe the result: no approval prompt, popup, or notification of any kind appears anywhere in the interface for the user to click "allow" or "deny."
2. Observe the tool call fails immediately instead, with one of these error strings depending on tool type:

• Skill tool: empty error, just <error>Execute skill: <skill name></error>
• Bash/PowerShell: This command requires approval
• MCP connector tool or file write: Claude requested permissions to use <tool>, but you haven't granted it yet. (or the write-specific variant, Claude requested permissions to write to <file path>, but you haven't granted it yet.)

1. Note that step 2's file-write case is the clearest minimal repro: attempt an Edit or file write to any file inside a folder already listed as an allowed working directory for the session. Since the directory itself is already authorized, this rules out a per-tool or per-scope explanation — the failure is in the approval-prompt UI not rendering in this interface at all, for any action needing a first-time grant.

No special code or file contents are needed to reproduce this — any first-time tool call in the affected interface triggers it. The minimal example is step 2's file-write case, since it needs no external connector or shell command, only a Claude Code session with at least one already-permitted directory and one not-yet-used write action inside it.

Filing status

• Drafted and approved by Rachel July 18, 2026.
• First filing attempt via gh issue create blocked by the same bug (gh auth status needed approval that never surfaced).
• Still open as of July 18, 2026 — see [[Active Priorities]] for current status.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.22209.0 (77c938) 2026-07-16T05:39:45.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional context

This occurred in a voice/text conversational interface layered on Claude Code, where assistant replies are spoken aloud (text-to-speech) rather than a bare terminal session — worth flagging in case the bug is specific to that voice-relay layer rather than every Claude Code surface.

The failure was consistent, not intermittent: seven separate attempts across one continuous session, on seven different tool types, failed the same way every time. No retry succeeded.

This is not a case of zero permissions ever being configured. The project's .claude/settings.local.json already had a working allow list in place before any of this session's failures began:

{
  "permissions": {
    "allow": [
      "mcp__visualize__read_me",
      "PowerShell(\"---\")",
      "PowerShell(foreach ($c in 'python','python3','py','node','npx') { $g = Get-Command $c -ErrorAction SilentlyContinue; if ($g) { \"$c -> $($g.Source)\" } else { \"$c -> NOT FOUND\" } })"
    ]
  }
}

Attempting to add four new entries to this same list, to work around the bug, failed with the identical permission error described above — so even editing the permissions file itself is blocked by the bug it would otherwise fix.

Filing status

• Drafted and approved by Rachel July 18, 2026.
• First filing attempt via gh issue create blocked by the same bug (gh auth status needed approval that never surfaced).
• Still open as of July 18, 2026 — see [[Active Priorities]] for current status.