Scheduled tasks cannot pre-authorize browser-tool permissions - unattended browser automation stalls on per-action prompts

Environment

• Claude desktop app (Windows, MSIX package) v1.24012.9.0, Claude Code SDK 2.1.219
• Windows 11 Pro 10.0.26200
• Local scheduled tasks (Cowork scheduler) driving browser automation (browser:navigate / browser:read_page_content / browser:click)

Summary

There is no way to durably pre-authorize browser-tool permissions for an unattended scheduled task. Every scheduled run re-prompts per browser action, so any scheduled task that drives the browser stalls unless a human is at the machine.

What we tried, with observed log behavior:

1. Answering browser prompts with "always" - records as decision=always and works for the rest of that run, but the grant is session-scoped: the next scheduled run logs Not auto-approving "browser:read_page_content" in scheduled task "<task>": rule(s) not in stored approvals and re-prompts from scratch.
2. settings.json permissions.allow - user-level allow rules (including mcp__claude-in-chrome) are not consulted by the scheduled-task lane at all (verified: explicit allow rule present, prompt still emitted).
3. Per-task Chrome permissions - the app clearly HAS a per-task durable store: one of our tasks (created through a different, earlier flow) shows Updated Chrome permissions for task "<task>" (mode=follow_a_plan, domains=3) in the log and browses without prompting. But for a task created via the scheduled-tasks MCP tools (create_scheduled_task) we found no UI surface that attaches this config - setting domains in the task settings produced no "Updated Chrome permissions" event and had no effect on prompting.

Impact

• Unattended browser-automation tasks (nightly cache scrapes, dashboard refreshes) stall on their first browser action when nobody is present.
• A stalled run also pins one of the scheduler's concurrency slots (observed caps: 3 active global / 1 per task), so a few stalled runs block ALL scheduled tasks on the machine - the failure cascades beyond the browser task itself.

Related (same class, lower impact)

• Edit/Write tool prompts in scheduled runs log suggestions contained no addRules/replaceRules - never bankable; we worked around it by rewriting runbooks to use shell file writes only.
• Some MCP tools (e.g. session-management archive_session) log no suggestions on request - also never bankable.

Request

A supported way to grant a scheduled task durable, domain-scoped browser permissions - e.g. expose the existing per-task Chrome permissions (follow_a_plan mode + allowed domains) in the scheduled task's settings UI, and/or honor settings.json permission allow rules in the scheduled-run lane.