Cowork / Claude in Chrome extension navigated a real Chrome tab to an unrelated external site (aisle.wedding) without any prompt requesting it

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Subagent behaved unexpectedly

What You Asked Claude to Do

No prompt asked Claude, Cowork, or the Claude in Chrome extension to visit aisle.wedding or anything wedding-related.

Two Cowork sessions were active around the incident dates. First, "BCD weekly social content", a manual (non-scheduled) run drafting social captions from Google Drive job records, which per its visible transcript plans a Meta Business Suite login step via the Chrome extension but never reaches it. Second, "BCD memory system administration", Google Drive file and governance administration work using heavy Claude-in-Chrome tool calls (browser_batch, computer, find) against Drive and a second reviewer tab.

Neither session's instructions reference any external site outside Google Drive or Meta Business Suite. I asked the Cowork account directly to self-report its scheduled tasks and session history; it confirmed only one scheduled task exists account-wide (a one-time, never-yet-fired quarantine review task with no browsing involved) and found nothing in either session's visible instructions that explains the navigation.

What Claude Actually Did

On at least 2026-07-20, a real Chrome tab (verified via Chrome's own History database, not just Claude's cache) navigated to https://aisle.wedding/ during a window when a Cowork-related process was active.

Two independent pieces of evidence support this. Bitdefender (Online Threat Prevention) logged 20+ outbound requests to aisle.wedding paths (root, /venues/..., /elena, /ingest/s/ which is a PostHog analytics beacon, and a /vitals endpoint) attributed to claude.exe, across three separate dates: 2026-07-15 around 15:04 and 16:59, 2026-07-17 around 15:00, and 2026-07-20 from 17:10 to 17:16 EDT.

I independently queried the real Chrome profile's History SQLite database (urls and visits tables joined) and found a matching top-level navigation: url https://aisle.wedding/, visit_time 2026-07-20 17:11:51 EDT, transition value 838860801 which decodes to TYPED with the HOME_PAGE, CLIENT_REDIRECT and CHAIN_END qualifiers, from_visit equal to 0 meaning no referring page exists in Chrome's own history, and a visit duration of about 14.6 seconds.

That transition signature is consistent with a browser extension setting a tab's URL programmatically, not a human typing the URL, not a link click, and not a redirect chained from another page Chrome was tracking.

Expected Behavior

Cowork and the Claude in Chrome extension should only navigate to domains relevant to the task actually given. Any navigation the extension performs, especially to a brand-new unrelated third-party domain, should be visible and attributable in the session's own tool-call transcript, so the user (or a later investigating Claude session) can see the exact URL argument and the reasoning that produced it. In this case Cowork's own self-report explicitly said it could not see the URLs its own browser tool calls had navigated to within its past sessions, which is the actual gap that made this hard to diagnose.

Files Affected

N/A - no files were modified. This report concerns an unexpected browser navigation to https://aisle.wedding/, not a filesystem action.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not reliably reproducible on demand. Known context: it happened on three separate dates (2026-07-15, 2026-07-17, 2026-07-20) while a Cowork session using Claude-in-Chrome browser tools for Google Drive administration was active or had recently run. No single prompt has been identified that triggers it consistently.

Claude Model

Sonnet

Relevant Conversation

Excerpt from Cowork's own self-report when asked to investigate this: "No other scheduled/recurring tasks exist, active, paused, or disabled. Two idle Cowork sessions with BCD-related work were found, neither registered in the scheduler despite one calling itself recurring in its own prompt text. Neither transcript exposes per-message timestamps to me, so I cannot confirm or rule out that either session's browser activity coincides with the incident windows. I don't see a cause in what I have access to."

That gap (Cowork tool-call transcripts not surfacing the actual URL arguments passed to its own browser tools) is the core reproducibility problem, not just this specific incident.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.215 (Claude Code, bundled via Claude Desktop at C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.215); Claude Desktop app version 1.22209.3.0

Platform

Anthropic API

Additional Context

Additional verification I did while investigating, ruling out other causes: all 5 claude.exe binaries on the machine (Claude Desktop, both bundled Claude Code CLI versions, both npm-installed CLI copies) carry valid Authenticode signatures from Anthropic, PBC, so this is not an impersonating/tampered binary. No unsigned or invalid-signature .exe/.dll files were dropped into any Claude app data folder in the last 14 days. Chrome's own homepage and startup-URL settings are unconfigured (no hijack), and the only installed Chrome extensions are Claude, ChatGPT, and standard Chrome system components, no rogue/unfamiliar extension. Live network connections from the Desktop app at investigation time only went to Anthropic, Google Cloud (Gmail/Drive connectors), and one Railway-hosted endpoint consistent with a configured MCP plugin connector; nothing unexplained.

aisle.wedding itself is a legitimate small business (a destination-wedding website builder), not malware; the concern here is entirely about an Anthropic product navigating there autonomously and unexplainably, not about the destination site being dangerous.