[BUG] Cowork Chrome extension: JS execution permission prompts fire on every call during manual tasks — approvals do not persist
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?
During manual Cowork tasks (not scheduled), the Chrome extension prompts for permission on every single JavaScript execution against an already-approved domain. Approvals do not persist — even within the same prompt response on the same domain.
Symptoms:
- "Allow Claude to use the browser on [domain]" / JS execution prompts fire repeatedly within a single manual Cowork task
- Clicking "Allow" or "Always allow" on each prompt has no persistent effect — the next JS call on the same domain prompts again
- Chrome extension options page → "Your approved sites" remains empty ("No sites have been approved yet") despite hundreds of approval clicks over multiple sessions
- claude.ai/settings/browser-extension → "Default for all sites" is set to "Allow extension" (only options available are "Allow extension" and "Block extension" — no third tier to bypass per-action prompts)
- Chrome-level site access for the extension is "On all sites"
- macOS, latest Claude Desktop
Reproduction:
- Set claude.ai/settings/browser-extension "Default for all sites" to "Allow extension"
- Start a manual Cowork task that requires multiple JS executions on a single domain (e.g., scraping listings, form automation on a known site like facebook.com)
- Approve the first JS execution prompt
- Observe: every subsequent JS call on the same domain prompts again, indefinitely
Expected: Once approved for a domain within a session, JS execution should not re-prompt for the same domain.
Impact: Manual Cowork browser automation is not viable in this state. A single task requiring tens to hundreds of JS calls produces tens to hundreds of identical permission prompts. Running real business automation on a Max plan (multi-location used car dealership operations across Facebook Marketplace, internal dashboards, and other trusted sites), this defeats the purpose of the product — it's faster to do the work manually than to click "Allow" hundreds of times.
Related issues: #30356 (scheduled-task variant of same bug), #37814 (file-edit variant), #46205 (folder-permission variant) — all describe the same underlying permission-storage failure manifesting in different contexts. This issue covers the manual-task + Chrome-extension + JS-execution combination, which is not yet covered by an existing issue.
What Should Happen?
Once a user approves a domain for browser/JS execution, subsequent JS execution calls on that same domain should not re-prompt for permission — at minimum within the same Cowork task, and ideally persisted across sessions when "Always allow" is selected.
Approvals should write to the Chrome extension's persistent permission storage (chrome.storage.local "permissionStorage" key), and the "Your approved sites" list at the extension options page should reflect each approved domain.
Error Messages/Logs
No error messages — issue is behavioral. The permission dialog repeatedly appears with text similar to:
"Allow Claude to use the browser on [domain]?"
"Allow Claude to execute JavaScript on this page?"
These prompts fire on every individual JS execution call within a manual Cowork task, with no error or warning generated. Approvals do not produce any visible failure — they simply do not persist.
Steps to Reproduce
- Open claude.ai/settings/browser-extension and confirm "Default for all sites" is set to "Allow extension"
- Confirm Chrome extension options (chrome-extension://[id]/options.html) shows "Your approved sites: No sites have been approved yet"
- Open Claude Desktop and start a new Cowork task manually (not scheduled)
- Give Cowork a task requiring multiple JS executions on a single domain. Example prompt:
"Open facebook.com/marketplace, search for 'used trucks under $20000' in my area, scroll through the first 20 listings, and extract the title, price, mileage, and seller location for each into a table."
- The first time Claude attempts a JS execution, a permission dialog appears
- Click "Allow" (or "Always allow" if shown)
- Observe: the next JS execution on the same facebook.com domain triggers the same prompt again
- Continue clicking "Allow" — the prompt fires on every subsequent JS call, throughout the entire task
- After the task ends, return to the Chrome extension options page — "Your approved sites" still shows "No sites have been approved yet"
Result: A task that should require 1 approval requires hundreds of approvals, and none of those approvals are written to persistent storage.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Approximately one week ago (week of April 20, 2026). Browser/JS approvals previously persisted as expected. Exact prior version unknown — Claude Desktop auto-updates.
Claude Code Version
N/A — bug occurs in Claude Desktop Cowork + Claude in Chrome extension, not Claude Code CLI. Running latest Claude Desktop (auto-updated).
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
This bug report is for Claude Desktop Cowork + Claude in Chrome extension, not Claude Code CLI. The Claude Code template is the only available bug report template, but the Cowork/Chrome extension issues are tracked in this same repository (see related issues #30356, #37814, #46205, all using this template).
Screenshots attached:
- claude.ai/settings/browser-extension showing "Default for all sites" set to "Allow extension"
- Chrome extension options page showing "Your approved sites: No sites have been approved yet" despite hundreds of approval clicks over the past week
Account: Max plan
Use case: Multi-location used car dealership (TheInternetCarLot.com) operations automation — Facebook Marketplace listing management, CRM workflow automation, inventory cross-posting. Real revenue-generating workflows currently blocked by this bug.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗