Repository navigation
docs(claude-md): default browser automation to reuse the active tab - #719
Merged
Merged
Conversation
Every `mcp__claude-in-chrome__navigate` call currently opens a new tab, so research sessions accumulate dozens of half-used tabs. The behavior isn't a bug in the tool — it's the absence of guidance in CLAUDE.md telling the agent to prefer same-host navigation in the active tab. Adds a one-paragraph default in the "Browser automation" section right after the tool-selection sentence: - Default: active tab when the next URL has the same host as the current tab. - New tab only for cross-origin navigation, when an existing tab is the only context holding relevant state (logged-in session, long- running app), or when the user explicitly asks. - Rationale included so future readers see why. Per Chi's 2026-05-14 ask. Doc-only change; no behavior change in code — the guidance lands in the prompt every agent session reads at boot. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Chi caught a wording precision issue: "same host" is ambiguous. By hostname, localhost:7844 and localhost:8080 share a host. By origin (Web spec: scheme + host + port), they're DIFFERENT — different services, different state, shouldn't share a tab. Replaces "same host" with "same origin (scheme + host + port)" and adds the localhost:7844 vs localhost:8080 example as a concrete disambiguator so future readers don't fall into the same trap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sonichi
commented
May 15, 2026
sonichi
left a comment
sonichi
left a comment
Owner
Author
There was a problem hiding this comment.
LGTM (cannot --approve own PR).
Diff: doc-only, +2/-0 to CLAUDE.md:233-area. Correctly captures the Web-spec definition of origin (scheme + host + port) and uses the localhost:7844 vs localhost:8080 example MacBook landed in chat as the canonical illustration of why same-hostname-different-port still spawns a new tab.
Behavior change is in-prompt only — CLAUDE.md is read at boot, so the guidance propagates to mcp__claude-in-chrome__navigate tool-selection without touching tool code. Test plan correctly flags this as observational.
Nit (non-blocking): the PR body summary still says "same host" while the diff says "same origin (scheme + host + port)" — diff is correct, body is the older draft. Doesn't affect merged behavior; either fix the body or leave.
Mergeable. Safe to land.
4 tasks
sonichi
added a commit
that referenced
this pull request
May 15, 2026
`open_url` previously always spawned a new Chrome tab — the voice agent calling it during a research flow leaves dozens of half-used tabs the same way `mcp__claude-in-chrome__navigate` did (which PR #719 just addressed for the core-agent CLAUDE.md path). This patches the voice-side surface: `open_url` now queries the active tab's URL, parses both origins (scheme + host + port), and reuses the active tab when they match. Cross-origin and unparseable URLs fall back to new-tab. Any osascript failure falls back to new-tab too — callers never silently lose the open. Tool description updated to describe the new behavior so Gemini's prompt sees it. Companion to PR #719 (which fixed the core-agent / CLAUDE.md path). Together they cover both navigation surfaces. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
liususan091219
pushed a commit
to liususan091219/sutando-fork
that referenced
this pull request
May 28, 2026
…onichi#719) * docs(claude-md): default browser automation to reuse the active tab Every `mcp__claude-in-chrome__navigate` call currently opens a new tab, so research sessions accumulate dozens of half-used tabs. The behavior isn't a bug in the tool — it's the absence of guidance in CLAUDE.md telling the agent to prefer same-host navigation in the active tab. Adds a one-paragraph default in the "Browser automation" section right after the tool-selection sentence: - Default: active tab when the next URL has the same host as the current tab. - New tab only for cross-origin navigation, when an existing tab is the only context holding relevant state (logged-in session, long- running app), or when the user explicitly asks. - Rationale included so future readers see why. Per Chi's 2026-05-14 ask. Doc-only change; no behavior change in code — the guidance lands in the prompt every agent session reads at boot. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fixup: clarify "same origin" (scheme+host+port), not "same host" Chi caught a wording precision issue: "same host" is ambiguous. By hostname, localhost:7844 and localhost:8080 share a host. By origin (Web spec: scheme + host + port), they're DIFFERENT — different services, different state, shouldn't share a tab. Replaces "same host" with "same origin (scheme + host + port)" and adds the localhost:7844 vs localhost:8080 example as a concrete disambiguator so future readers don't fall into the same trap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
liususan091219
pushed a commit
to liususan091219/sutando-fork
that referenced
this pull request
May 28, 2026
`open_url` previously always spawned a new Chrome tab — the voice agent calling it during a research flow leaves dozens of half-used tabs the same way `mcp__claude-in-chrome__navigate` did (which PR sonichi#719 just addressed for the core-agent CLAUDE.md path). This patches the voice-side surface: `open_url` now queries the active tab's URL, parses both origins (scheme + host + port), and reuses the active tab when they match. Cross-origin and unparseable URLs fall back to new-tab. Any osascript failure falls back to new-tab too — callers never silently lose the open. Tool description updated to describe the new behavior so Gemini's prompt sees it. Companion to PR sonichi#719 (which fixed the core-agent / CLAUDE.md path). Together they cover both navigation surfaces. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a one-paragraph default to
CLAUDE.md"Browser automation" section (right after the tool-selection sentence, line 233 area):Why
Per Chi 2026-05-14 discussion. The current behavior — every navigate-call spawns a fresh tab — isn't a bug in the underlying tool; it's the absence of guidance in
CLAUDE.mdtelling the agent to prefer same-host navigation in the active tab. Result: after a 5-step research flow you have 5 tabs all on (say) github.com when 1 would have done.CLAUDE.md is the prompt every agent session reads at boot, so doc-only changes here do propagate to behavior.
Test plan
mcp__claude-in-chrome__navigatecalls — same-host navigations should reuse the tab; cross-origin should spawn new. Behavior change is in the LLM's tool-selection, not in tool code, so verification is observational.Scope
CLAUDE.mdonly (+2/-0). No code changes.🤖 Generated with Claude Code