Claude in Chrome: browser permission dialog reappears on every scheduled task run

Bug Report: Chrome Extension Permission Dialog Reappears on Every Scheduled Task Run

Summary

The "Allow Claude to use the browser on [domain]" permission dialog appears every time a scheduled task runs, despite clicking "Allow all browser actions." The permission does not persist between sessions, making scheduled browser tasks require manual intervention on every run.

Environment

• Claude Desktop (Cowork mode)
• Claude in Chrome extension ID: hgoppfmeamohhpdlgmbondkfcijhklbo
• Two scheduled tasks using Chrome browser tools on admin.booking.com
• Tasks have allowed-tools properly configured in SKILL.md frontmatter

Steps to Reproduce

1. Create a scheduled task that uses Chrome browser tools (navigate, read_page, find, etc.)
2. Include allowed-tools in the SKILL.md frontmatter listing all required MCP tools
3. Run the task (manually or on schedule)
4. When the "Allow Claude to use the browser on admin.booking.com?" dialog appears, click "Allow all browser actions"
5. Wait for the task to complete
6. Run the task again (or wait for the next scheduled run)

Expected Behavior

After clicking "Allow all browser actions," the permission should persist across sessions. Subsequent task runs should not show the permission dialog.

Actual Behavior

• The permission dialog appears on every single task run
• The extension's Settings → Permissions → "Your approved sites" shows "No sites have been approved yet" even after clicking "Allow all browser actions" dozens of times
• The setting is not saved anywhere

Root Cause Analysis (from reverse-engineering the extension code)

We inspected the extension's source code (mcpPermissions-D-cKe6e4.js and PermissionManager-Dh53JkTm.js) and found:

1. Bridge permission mode is session-only

In mcpPermissions, when a tool request comes from the bridge (Cowork), the permissionMode is read from the bridge message, NOT from persistent storage:

// From mcpPermissions-D-cKe6e4.js (deobfuscated)
if ("bridge" === e.source) {
    const t = function(e, t) {
        if (!e || "ask" === e) return;  // "ask" = show dialog
        const r = "skip_all_permission_checks" === e;
        const o = new PermissionManager(() => r, {});
        return "follow_a_plan" === e && t?.length && o.setTurnApprovedDomains(t), o;
    }(e.permissionMode, e.allowedDomains);
}

When permissionMode is "ask" or undefined (which is what Cowork sends for scheduled tasks), no PermissionManager is created, and the onPermissionRequired callback sends a permission_request back to Cowork, which displays the dialog.

2. Per-site permissions exist but are never checked for bridge requests

The extension stores per-site permissions in chrome.storage.local under the key "permissionStorage" with this structure:

{
    "permissions": [{
        "id": "uuid",
        "scope": { "netloc": "admin.booking.com" },
        "action": "allow",
        "duration": "always",
        "createdAt": 1234567890
    }]
}

However, this storage is ONLY checked when a PermissionManager instance exists. For bridge requests with permissionMode: "ask", no PermissionManager is created, so per-site permissions are never consulted.

3. "Allow all browser actions" button doesn't persist

The button appears to set a session-level flag but does NOT:

• Write to permissionStorage in chrome.storage.local
• Update lastPermissionModePreference in storage
• Add the domain to any approved sites list

This is why "Your approved sites" remains empty despite repeated clicks.

What We Tried (none worked)

1. Clicking "Allow all browser actions" — resets every session
2. settings.local.json with bypassPermissions and MCP tool allow rules — only affects Claude Code tool permissions, not Chrome domain permissions
3. Writing permissionStorage directly to chrome.storage.local — data is stored but not read for bridge requests
4. Setting lastPermissionModePreference: "skip_all_permission_checks" — Cowork ignores this when determining what permissionMode to send
5. Setting browserControlPermissionAccepted: true — already was true, has no effect on per-domain checks

Suggested Fix

One of these approaches would fix the issue:

Option A: When Cowork sends a bridge request for a scheduled task, set permissionMode to "skip_all_permission_checks" instead of "ask". Scheduled tasks are explicitly configured by the user and should not require runtime permission confirmation.

Option B: Make the "Allow all browser actions" button actually persist the setting by writing to storage (e.g., lastPermissionModePreference: "skip_all_permission_checks") and have Cowork read this value when determining the permissionMode for bridge requests.

Option C: When permissionMode is "ask", check permissionStorage for per-site "always allow" entries BEFORE sending a permission_request back to Cowork. This way the existing "Always allow actions on this site" mechanism would work for bridge requests too.

Impact

This bug makes scheduled browser tasks unusable for automation — the user must be present to click "Allow" every time, defeating the purpose of scheduling.