--browser-attach-running fails on Chrome 151: discovery needs a DevToolsActivePort file Chrome no longer writes

[devYRPauli]

Summary

--browser-attach-running cannot find a browser on Chrome 151, even when the DevTools endpoint is live and answering. Attach discovery looks for a DevToolsActivePort file in the user data directory, and Chrome 151 does not write one.

Every attach run fails with:

ERROR: No running browser with attach metadata matched 127.0.0.1:9222. Enable remote debugging in chrome://inspect/#remote-debugging first.

The message points at remote debugging, which is already enabled, so it sends you looking in the wrong place.

Environment

• oracle 0.18.0
• Chrome 151.0.7922.174
• macOS, Apple silicon

Reproduction

Start Chrome with remote debugging and a user data directory under the macOS discovery root:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/Library/Application Support/AttachProfile" \
  --no-first-run --no-default-browser-check https://chatgpt.com/

Confirm the endpoint is up:

curl -s http://127.0.0.1:9222/json/version
# {"Browser":"Chrome/151.0.7922.174","Protocol-Version":"1.3", ... }

Chrome's own stderr also reports it:

DevTools listening on ws://127.0.0.1:9222/devtools/browser/609117bf-...

Then run any attach command:

oracle --engine browser --browser-attach-running -p "Reply with OK." -f some.jpg
# ERROR: No running browser with attach metadata matched 127.0.0.1:9222.

The user data directory contains no DevToolsActivePort file:

find "$HOME/Library/Application Support/AttachProfile" -maxdepth 3 -name DevToolsActivePort
# (no output)

Cause

resolveAttachRunningConnection (src/browser/attachRunning.ts) calls discoverDevToolsActivePortCandidates (src/browser/detect.ts:223), which walks the roots from resolveDevToolsActivePortDiscoveryRoots (src/browser/detect.ts:143, ~/Library/Application Support on macOS) looking for DevToolsActivePort files.

Discovery is therefore file-based. It never contacts the endpoint the user asked for. When Chrome does not write that file, candidates is empty and attachRunning.ts:36 throws, regardless of whether 127.0.0.1:9222 is serving.

Workaround

Writing the file by hand makes attach work immediately:

WS=$(curl -s http://127.0.0.1:9222/json/version | jq -r .webSocketDebuggerUrl)
printf '9222\n%s\n' "${WS#ws://*[0-9]}" > "$HOME/Library/Application Support/AttachProfile/DevToolsActivePort"

After that the same command connects and completes normally, including attachment upload and submission.

Suggested direction

Two options, both small:

1. When an explicit host and port are known, probe http://host:port/json/version first and use webSocketDebuggerUrl from the response. Fall back to file discovery only when that fails. This removes the dependency on a Chrome implementation detail for the case where the user already told you where the browser is.
2. Keep file discovery, but on failure say what was actually looked for, for example "no DevToolsActivePort file found under <root>; the endpoint at 127.0.0.1:9222 was not probed". The current message sends people to chrome://inspect, which does not help.

Option 1 also fixes the case where the profile lives outside the platform discovery root, which is easy to hit with a throwaway profile in /tmp.

I am happy to send a PR for either if you have a preference.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 25, 2026, 3:11 PM ET / 19:11 UTC.

Summary
Keep open: current main still throws when no DevToolsActivePort metadata exists, and the formally linked open PR is the focused repair path.

Reproducibility: yes. —source inspection provides a high-confidence path: an empty metadata discovery result deterministically reaches the throw, matching the supplied live-endpoint reproduction.

Root-cause cluster
Relationship: canonical
Canonical: #414
Summary: This issue is the canonical report; the linked open pull request is its focused implementation candidate.

Members:

• fixed_by_candidate: fix(browser): probe the DevTools endpoint when attach discovery finds nothing #415 - Its body formally closes this issue and implements the endpoint-probe fallback for the documented empty-metadata path.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The linked open PR already owns this bounded repair, so a second fix PR would duplicate active work.

Review details

Best possible solution:

Preserve metadata discovery as the first choice, then fall back to the explicit local /json/version endpoint when discovery is empty, with IPv4 and IPv6 regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes—source inspection provides a high-confidence path: an empty metadata discovery result deterministically reaches the throw, matching the supplied live-endpoint reproduction.

Is this the best way to solve the issue?

Yes—the linked PR's narrow fallback keeps the existing successful metadata path intact and addresses the only failing empty-discovery branch.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The repair is not yet merged, so users on current main and v0.17.3 still fail when Chrome exposes a live endpoint without a metadata file.

Codex review notes: model internal, reasoning high; reviewed against 79e483bd9dc8.

Label changes

Label justifications:

• P1: A core browser workflow fails for users who have already enabled local remote debugging and supplied a reachable endpoint.
• impact:other: The failure is local browser-attach discovery and does not fit the more specific owned impact categories.

Evidence reviewed

What I checked:

• Current failure path: Current main discovers only DevToolsActivePort files, filters them by the requested port, and throws when the result is empty; it does not probe the configured endpoint. (src/browser/attachRunning.ts:30, 79e483bd9dc8)
• Documented attach contract: The browser-mode documentation says attach-running accepts an explicit local host:port hint but reads local DevToolsActivePort metadata to connect. (docs/browser-mode.md:60, 79e483bd9dc8)
• Released behavior remains unchanged: The current attach implementation is byte-identical to v0.17.3, so the reported empty-metadata path exists in the latest released baseline as well as current main. (src/browser/attachRunning.ts:30, 6b17e6db0cae)
• Feature provenance: History identifies the direct-CDP attach feature commit, with later release integration by Peter Steinberger. (src/browser/attachRunning.ts:14, 1f36413f89df)
• Linked implementation candidate: The issue timeline and PR body formally link the open, clean PR as the candidate fix; it preserves metadata discovery and adds the endpoint fallback with reported Chrome 151 after-fix evidence. (edf26a08e977)

Likely related people:

• Peter Dedene: Introduced the direct-CDP attach-running feature that owns the failing discovery path. (role: feature introducer; confidence: high; commits: 1f36413f89df; files: src/browser/attachRunning.ts, src/browser/detect.ts)
• Peter Steinberger: Current released lines blame to the release integration commit, and history shows repeated work on this browser surface. (role: recent area contributor; confidence: medium; commits: 6b17e6db0cae, 422e35fb6688; files: src/browser/attachRunning.ts, src/browser/detect.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.