Connector tools set to "Needs approval" are silently denied in Cowork auto mode — no prompt is ever shown

### What happened?

In a Cowork session with auto mode active, MCP connector tools left at the default "Needs approval" permission are denied by the auto-mode classifier **without any approval prompt ever being surfaced to the user**. I was present and attending the session for its entire duration and was never prompted.

The denial is silent from the user's side and visible only in the agent's tool results. Because it surfaces as a tool error rather than a pending approval, the natural read is "the connector is broken" — which cost us a substantial detour before we isolated it.

Concretely: read-only Gmail tools (set to "Always allow") succeeded throughout. Write tools (`trash_thread`, `unlabel_thread`) at the default "Needs approval" returned:

```
Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier.
```

No prompt appeared — not in the desktop app, not in the session, nowhere I could see or act on it. Nothing indicated that an approval was ever wanted.

### Secondary observation: nondeterministic error strings in the parallel write path

A single batch of 11 concurrent write calls (10 × `trash_thread`, 1 × `unlabel_thread`), all identical in shape and all against the same connector, returned **two different errors nondeterministically**:

- 3 calls → `Permission for this action was denied by the Claude Code auto mode classifier.`
- 8 calls → `MCP server "Gmail" requires re-authorization (token expired)`

Re-running a *single* call serially reproduced the classifier denial every time. This suggests a race in the parallel write path, where concurrent calls surface an authorization error instead of the classifier denial that actually applies.

### Interaction with the mislabeled 403 (see anthropics/claude-code#44652)

Toggling the write tools to "Always allow" removed the classifier denial and revealed a second, distinct problem underneath: the connector held read scope but not write scope, and every write returned `MCP server "Gmail" requires re-authorization (token expired)`.

That message is false. Two calls seconds apart, same session, same connector:

- `trash_thread` → "requires re-authorization (token expired)"
- `search_threads` → returned the inbox normally

A token cannot be expired for one call and valid for the next. This matches anthropics/claude-code#44652, where a 403 `insufficient_scope` is reported to the user as a token expiry and the step-up re-authorization flow never runs. That issue was filed against a custom MCP server enforcing its own scopes; this is a **first-party Gmail connector doing it during ordinary use**.

Notably the connector showed a **green checkmark in Settings throughout** — correctly, since the token was valid; it simply lacked the scope. Nothing in the UI indicated a scope problem. Disconnecting and reconnecting the connector, so all scopes are granted in the initial consent, resolved it.

### Why these are worth reporting together

They stack into something very hard to diagnose from the user's side:

1. The permission layer denies without asking, so the user has no idea approval was wanted.
2. When that layer is cleared, the layer beneath reports a false cause ("token expired").
3. Settings shows the connector as healthy, because by its own lights it is.

Each layer independently points away from the actual problem. A user without visibility into raw tool results has essentially no path to the real cause.

### What did you expect to happen?

An approval prompt should be presented to the user, who is present and attending the session.

If prompting is genuinely impossible in a Cowork auto-mode context, the error should say so plainly rather than reporting a bare classifier denial, and it should name the specific tool and its current permission setting so the user knows which toggle to change.

Suggested fixes:

- Surface an approval prompt for "Needs approval" tools in Cowork auto mode when a user is attending; if that is not possible, make the error explain why.
- Have the classifier denial name the tool and its current permission setting.
- Serialize or fix the race in the parallel write path so concurrent calls report the authorization state that actually applies.
- Distinguish 403 `insufficient_scope` from token expiry in user-facing errors, and reflect insufficient scope in the connector's Settings status rather than showing a green checkmark.

### Steps to reproduce

1. In a Cowork session with auto mode active, connect the Gmail connector.
2. Set the connector's read-only tools to "Always allow". Leave the write/delete tools at their default "Needs approval".
3. Have the agent call read-only tools (`search_threads`, `get_thread`). These succeed.
4. Have the agent call a write tool (`trash_thread` or `unlabel_thread`).
5. Observe: the call is denied by the auto-mode classifier and **no approval prompt appears anywhere**, even with the user present and watching the session.

To surface the second, underlying problem:

6. Set the write/delete tools to "Always allow". The classifier denial stops.
7. Call a write tool again → `MCP server "Gmail" requires re-authorization (token expired)`.
8. Immediately call a read tool → succeeds normally, proving the token is valid and the real fault is insufficient scope (403), not expiry.
9. Disconnect and reconnect the connector, granting all scopes at the consent screen → writes succeed.

To reproduce the nondeterministic error split: issue ~11 write calls in a single parallel batch and observe that some return the classifier denial and others return the false "token expired", with no difference between the calls.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Gmail (first-party claude.ai connector); Google Calendar showed the same scope behavior

### Error messages or logs

```shell
Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier.

MCP server "Gmail" requires re-authorization (token expired)
```

### Additional context

**Environment**

- Claude Cowork (cloud session linked to the desktop app)
- Claude desktop app 1.46388.4
- macOS Tahoe 26.6.2
- Connector: Gmail (first-party claude.ai connector)
- Permission config at time of failure: read-only tools → "Always allow"; write/delete tools → "Needs approval" (default, untouched)

**Related**

- anthropics/claude-code#44652 — 403 `insufficient_scope` surfaced as "token expired"; step-up re-auth never runs. Closed as not planned. Filed against a custom MCP server; this report is the same failure on a first-party connector.
- #491 — Cowork custom connector prompting on *every* tool call with "Allow all for this task" greyed out. That is the inverse of this report (prompts on all calls vs. prompts on none), which may indicate a common broken prompt path failing in both directions.

**Resolution in our case**

Setting the write tools to "Always allow" cleared the classifier denial; disconnecting and reconnecting the Gmail connector (granting all scopes at the consent screen) cleared the false "token expired". Both were needed. Neither was discoverable from any user-facing surface.