[Bug] attach failed: chrome-extension:// URL error persists in v1.7.12 (macOS)
- Dominant language
- JavaScript
- Stars
- 29.3k
- Forks
- 2.9k
- Avg merge
- 15h 36m
- Merged PRs (30d)
- 70
Description
## Description
`opencli xiaohongshu search`, `opencli bilibili hot`, and all browser-backed adapter commands fail with:
```
attach failed: Cannot access a chrome-extension:// URL of different extension. Tip: another Chrome extension may be interfering — try disabling other extensions
```
This is the same error reported in #249, which was reportedly fixed by #251. However, the issue persists in v1.7.12.
## Key Finding
**The bug reproduces even with a completely clean Chrome profile (zero extensions):**
```bash
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
--remote-debugging-port=9222 \
--user-data-dir=/tmp/chrome-clean-test \
--no-first-run "about:blank" &
OPENCLI_CDP_ENDPOINT="http://localhost:9222" opencli bilibili hot --limit 3
# → Same error: attach failed: Cannot access a chrome-extension:// URL of different extension
```
This proves the issue is **NOT caused by other Chrome extensions interfering**, contradicting the error message. The root cause lies within OpenCLI's own tab resolution or CDP attach logic.
## Steps to Reproduce
1. Install OpenCLI v1.7.12 on macOS
2. Install OpenCLI Chrome extension from Web Store
3. Run `opencli doctor` — all checks pass (daemon OK, extension connected)
4. Ensure Chrome active tab is a normal webpage (e.g. `https://www.baidu.com`)
5. Run any browser-backed adapter: `opencli bilibili hot --limit 3`
6. Observe: a new Chrome window opens briefly, then error appears
## Environment
- **OS**: macOS Darwin 25.4.0
- **OpenCLI**: v1.7.12 (latest)
- **Node.js**: v24.11.0
- **Chrome**: 147.0.7727.138
- **OpenCLI Extension**: v1.0.5 (from Chrome Web Store)
## Verbose Output
```
$ opencli bilibili hot --limit 3 -v
[1/4] navigate → https://www.bilibili.com
ok: false
error:
code: UNKNOWN
message: attach failed: Cannot access a chrome-extension:// URL of different extension. Tip: another Chrome extension may be interfering — try disabling other extensions
exitCode: 1
stack:
BrowserCommandError: attach failed: ...
at sendCommandRaw (daemon-client.js:115:23)
at async Page.goto (page.js:80:17)
at async stepNavigate (browser.js:14:9)
at async executeStepWithRetry (executor.js:50:20)
at async executePipeline (executor.js:24:28)
```
The error occurs at the `navigate` step, before any page interaction.
## Additional Notes
- Non-browser commands work fine: `opencli hackernews top --limit 3` returns correct results
- `opencli browser tab new ` sometimes succeeds in opening pages
- `opencli browser tab list` returns empty `[]` after session reset, even with tabs open
- `opencli doctor` consistently reports all green: daemon running, extension connected, connectivity OK
- Tested with all non-OpenCLI extensions disabled — same result
- Tested with clean Chrome profile + CDP endpoint — same result
## Suggested Investigation
Since #251 added `resolveTabId()` URL validation, the issue may be in:
1. The automation window itself being created with a `chrome-extension://` URL
2. `ensureAttached` probe logic failing to detect the bad state before navigate
3. Chrome 147 behavior change around new tab URL handling on macOS
Thank you for this great tool! Happy to help test any fixes.
Contributor guide
Research direction
Reproduce the failure with `opencli bilibili hot --limit 3 -v` against the clean Chrome profile and CDP endpoint described. Start with `daemon-client.js`, `page.js`, `browser.js`, and `executor.js`, then inspect the `resolveTabId()` and `ensureAttached` paths mentioned in the report. Done means browser-backed adapter navigation and `opencli browser tab list` work with a clean profile without the chrome-extension URL error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100