OPENCLI_CDP_ENDPOINT only works for Electron apps, ignored for cookie-mode sites like YouTube

[pedh]

Bug Description

When OPENCLI_CDP_ENDPOINT is set, opencli correctly uses CDP for Electron apps, but ignores it for non-Electron sites that require browser sessions (cookie mode). Commands like opencli youtube search still force the Browser Bridge extension and fail with:

```
🔌 Browser Bridge not connected
Daemon ✓ running
Extension ✗ not connected
```

Root Cause

Two places in the code only check OPENCLI_CDP_ENDPOINT for Electron apps:

1. dist/src/runtime.js — `getBrowserFactory()`
```js
export function getBrowserFactory(site) {
if (site && isElectronApp(site))
return CDPBridge; // only Electron → CDPBridge
return BrowserBridge; // everything else → requires extension
}
```

2. dist/src/execution.js — browser session setup
```js
const electron = isElectronApp(cmd.site);
let cdpEndpoint;
if (electron) {
// Only checks OPENCLI_CDP_ENDPOINT here
const manualEndpoint = process.env.OPENCLI_CDP_ENDPOINT;
...
} else {
// Non-Electron: throws if extension not connected
throw new BrowserConnectError("Browser Bridge extension not connected", ...);
}
```

Expected Behavior

When OPENCLI_CDP_ENDPOINT is set, it should work for all browser-based commands, not just Electron apps. The CDP endpoint is designed to reuse an already-authenticated browser instance — that is the whole point of it.

Reproduction

```bash
export OPENCLI_CDP_ENDPOINT="http://localhost:9222"
opencli youtube search opencli

→ "Browser Bridge not connected" (exit code 69)

```

Proposed Fix

runtime.js:
```js
export function getBrowserFactory(site) {
if (process.env.OPENCLI_CDP_ENDPOINT)
return CDPBridge;
if (site && isElectronApp(site))
return CDPBridge;
return BrowserBridge;
}
```

execution.js:
```js
const electron = isElectronApp(cmd.site);
const manualEndpoint = process.env.OPENCLI_CDP_ENDPOINT;
let cdpEndpoint;
if (manualEndpoint) {
const port = Number(new URL(manualEndpoint).port);
if (!await probeCDP(port)) {
throw new CommandExecutionError(...);
}
cdpEndpoint = manualEndpoint;
} else if (electron) {
cdpEndpoint = await resolveElectronEndpoint(cmd.site);
} else {
// Browser Bridge: only require extension when no CDP endpoint
...
}
```

Impact

This makes OPENCLI_CDP_ENDPOINT unusable for any non-Electron site (YouTube, Twitter, etc.), which defeats the purpose of CDP mode — reusing an already-logged-in browser without installing the extension.

[Astro-Han]

Confirmed. I checked the current source, and the core report is correct. There are a few separate issues here:

• src/runtime.ts:10-13 only returns CDPBridge for Electron sites. Non-Electron browser commands still get BrowserBridge, even when OPENCLI_CDP_ENDPOINT is set.
• src/execution.ts:163-191 only reads OPENCLI_CDP_ENDPOINT inside the Electron branch. For cookie-mode sites, the non-Electron branch still goes straight to Browser Bridge checks and can throw Browser Bridge extension not connected.
• src/browser/bridge.ts:31 does not accept cdpEndpoint, so the cdpEndpoint passed through browserSession() in src/runtime.ts:70-85 and src/execution.ts:224 is ignored on the Browser Bridge path. This is not just an execution-path bug. The factory selection also has to change.

A couple of related paths have the same problem:

• src/cli.ts:27-32 hardcodes new BrowserBridge() for opencli operate ..., so those commands ignore OPENCLI_CDP_ENDPOINT too.
• src/doctor.ts:42-49 and src/doctor.ts:56-64 also hardcode BrowserBridge. That matters because docs/advanced/cdp.md:89-100 tells users to run opencli doctor in CDP mode, but doctor currently validates only the extension path.
• src/cli.ts:173-180, src/cli.ts:212-218, src/cli.ts:243-249, and src/cli.ts:268-275 call getBrowserFactory() without a site, so built-in browser commands like explore, generate, record, and cascade also cannot pick CDP mode from OPENCLI_CDP_ENDPOINT.

One more detail: the proposed execution.js patch still probes manual endpoints by numeric port. That works for http://localhost:9222, but it does not fit the reverse-proxy https://... endpoint documented in docs/advanced/cdp.md. So the validation step probably needs to accept full HTTP/HTTPS CDP endpoints, not just local port probes.

So yes, the bug is real, and the scope is a bit wider than the original report. The fix likely needs to do three things together:

1. Prefer CDPBridge whenever OPENCLI_CDP_ENDPOINT is set, not only for Electron sites.
2. Route operate, doctor, and the built-in browser commands through the same browser-factory selection logic so CDP mode behaves the same everywhere.
3. Make manual endpoint validation work for both local http://127.0.0.1:9222 endpoints and proxied https://... CDP endpoints.

I'll take a look at a patch that covers the full set rather than only the youtube search path.

[Astro-Han]

Opened a fix for this in #869.

What changed:

• honor OPENCLI_CDP_ENDPOINT for non-Electron browser execution paths
• route operate through the shared browser factory
• trim manual CDP endpoints before use in the CDP transport
• add regression coverage for runtime routing, execution routing, operate, and CDP endpoint trimming

Targeted regression tests are passing on the fix branch.