[BUG] Computer-use request_access fails instantly (no dialog) on every unattended Cowork scheduled task run — macOS

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?

On every unattended (headless) run of a Cowork scheduled task, any attempt to request computer-use access to a native macOS app (tested with Calendar, Mail, Finder) fails immediately with an error — no approval dialog is shown, and there is no retry/stall behavior. This makes computer-use permanently unusable inside scheduled tasks, even though the exact same request_access calls succeed instantly when the user is present and grants access live in chat.

This is distinct from the general "Always allow" persistence bug reported in issue #47180 (which describes prompts reappearing and stalling the run for connector/MCP tools like Slack and Gmail). In this case there is no prompt at all — the tool call returns a hard error and the run continues without ever having a chance to be approved.

Environment: macOS, Claude Desktop, Cowork scheduled task ("morning-briefing," cron-based, fires ~6:30 AM ET on weekdays), Pro/Max plan. Reproduced on multiple consecutive days, most recently 2026-07-28.

What Should Happen?

One of the following:

1. A way to pre-authorize specific apps for a specific scheduled task, so unattended runs can use computer-use without a live human present — or
2. If that's out of scope for the trust model, the error message should not reference a nonexistent workaround. The message says "add the app to the scheduled task's settings," but there is no such setting exposed anywhere — not in the scheduled task's prompt/schedule/enabled/notify fields (checked via the update_scheduled_task tool schema), and not findable in the Desktop app's Scheduled task detail UI. This is misleading and sends users looking for a setting that doesn't exist.

Error Messages/Logs

Computer-use access to "Calendar" can't be approved during a scheduled run. To grant it, send a message in this conversation (the approval card will appear), or add the app to the scheduled task's settings. (Retrying returns this same result.)

Same result for "Mail" and "Finder" in the same run. No approval card is ever shown to the user (there is no one present to show it to), and retrying the exact same call in the same run deterministically returns the identical error.

Steps to Reproduce

1. Create a Cowork scheduled task whose prompt calls mcp__computer-use__request_access for a native macOS app (e.g., apps: ["Calendar"]).
2. Let the task fire unattended (Mac awake, Claude Desktop open, but no user actively present/watching).
3. Observe the tool call's response — it fails instantly with the error quoted in "Error Messages/Logs" above.

Additional test: run the task manually via "Run now" with the user present and grant access live, then wait for the next unattended scheduled fire. The next unattended run still fails with the same error — live "Run now" approval does not carry over to future headless runs.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — Cowork mode (Claude Desktop app), not the Claude Code CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Live/interactive grants work fine: when the user is present in chat and calls request_access themselves (or asks Claude to), the approval card appears and access is granted normally, at "full" tier, for Calendar, Mail, and Finder alike. Confirmed working live on 2026-07-27 and 2026-07-28.

Because Apple doesn't expose a public cloud API for Mail/Calendar/Finder (unlike Gmail/Google Calendar, which are reachable via OAuth-based connectors that work headlessly once linked), computer use is currently the only path to these apps at all — so this gap makes any Apple-native-app step of a scheduled task a dead end, every single day, without exception.

Related but distinct: #47180 ("Always allow" folder/tool permissions don't persist across scheduled runs — prompts reappear and stall the run). That issue is about prompts re-appearing for connector/MCP tools. This issue is about computer-use specifically never getting a prompt at all during unattended runs, which appears to be by design rather than a persistence bug — but the error message's advertised workaround doesn't exist, which is the actionable bug here.

Impact: any scheduled task that needs to touch a native macOS app (Mail, Calendar, Finder, Notes, Reminders, Photos, etc.) cannot do so unattended. The only current workaround is for the user to be physically present and grant access live in chat at the moment the task runs — which defeats the purpose of scheduling it. Current daily workaround: skip the computer-use steps gracefully during unattended runs and note in the output that Calendar/Mail couldn't be checked.