zhihu question command fails with 'Not logged in' despite valid session

[Gogoworks]

Bug Description

opencli zhihu question <id> always fails with 🔒 Not logged in to www.zhihu.com, even when the user is logged in to Zhihu in the browser profile where the Browser Bridge extension is installed.

Other Zhihu commands (e.g. zhihu search) work correctly with the same login session.

Environment

• opencli: v1.5.6
• Extension: v1.5.5
• OS: macOS (Darwin 25.4.0)
• Node: v22.22.1

Steps to Reproduce

1. Install Browser Bridge extension in a Chrome profile that is logged in to zhihu.com
2. Verify opencli zhihu search "any query" works (it does)
3. Run opencli zhihu question 2021881398772981878
4. Result: 🔒 Not logged in to www.zhihu.com

Root Cause

In src/clis/zhihu/question.ts, the command calls page.evaluate() with fetch(..., {credentials: 'include'}) directly, without first navigating to the Zhihu domain. Since the browser context is not on www.zhihu.com, cookies are not attached to the fetch request, and the Zhihu API returns an auth error.

In contrast, src/clis/zhihu/search.yaml includes a navigate: https://www.zhihu.com step before the evaluate, which establishes the correct domain context for cookies to be sent.

Suggested Fix

Add a navigation step in question.ts before the page.evaluate() call:

await page.goto('https://www.zhihu.com');

This matches the pattern used in search.yaml and should allow credentials: 'include' to work correctly.

[Astro-Han]

Checked the current repo state and the suggested root cause here looks outdated.

zhihu question does not rely only on src/clis/zhihu/question.ts for domain navigation anymore. Since commit a228758 on March 21, 2026, browser commands with Strategy.COOKIE / Strategy.HEADER are pre-navigated in src/execution.ts via resolvePreNav() before the adapter func runs. zhihu/question.ts already has:

• domain: 'www.zhihu.com'
• strategy: Strategy.COOKIE

So in current main, and also in the local v1.5.5 tag I checked, execution should already pre-navigate to https://www.zhihu.com before the page.evaluate(...fetch(..., { credentials: 'include' })) call.

A few things here do not line up yet:

1. This repo currently declares 1.5.5 in package.json, and the latest local tag is also v1.5.5.
2. The issue reports opencli v1.5.6, which I cannot correlate to a tag in the repo state I checked.
3. Because of that, I am not confident the failure is caused by a missing goto in question.ts.

Could you please help confirm:

• exact output of opencli --version
• exact output of opencli doctor
• whether this still reproduces on the latest published package / current main
• verbose output from:
  opencli zhihu question 2021881398772981878 -v

If it still reproduces with current code, the next place to inspect is the execution boundary: whether pre-navigation actually succeeds in the Browser Bridge session before the adapter evaluate() runs, rather than adding another page.goto() inside question.ts.

[Gogoworks]

Thanks for the thorough review @Astro-Han. You're right — my root cause analysis was incorrect.

After further testing, the real issue is that the Browser Bridge extension intermittently disconnects, and the error message differs depending on the code path:

• With -v flag: correctly shows 🔌 Browser Bridge not connected
• Without -v flag: shows 🔒 Not logged in to www.zhihu.com (misleading)

When the extension IS connected, zhihu search and twitter profile both work fine. When it disconnects (which seems to happen after Chrome idles or restarts), ALL browser-dependent commands fail — but zhihu question surfaces the error as "Not logged in" instead of "Bridge not connected".

So there are actually two separate issues:

1. Misleading error message: zhihu question (and possibly other Strategy.COOKIE commands) throws AuthRequiredError when the bridge is disconnected, masking the real connectivity problem. The non-verbose path doesn't distinguish between "no cookie" and "no bridge".

2. Extension connectivity instability: opencli doctor consistently reports Extension: not connected even when commands actually work (we confirmed via lsof that Chrome had an ESTABLISHED connection to the daemon on port 19825). The connectivity detection seems unreliable.

Here's the requested debug output:

$ opencli --version
1.5.6

$ opencli doctor
opencli v1.5.6 doctor (node v22.22.1)
[OK] Daemon: running on port 19825
[MISSING] Extension: not connected
[FAIL] Connectivity: failed

$ opencli zhihu question 2021881398772981878 -v
🔌 Browser Bridge not connected
  Daemon    ✓ running
  Extension ✗ not connected

Environment:

• macOS Darwin 25.4.0
• Node v22.22.1
• Extension v1.5.5 (from v1.5.6 release assets)
• Chrome Profile 6 with Developer Mode extension loaded

Happy to provide more debug info if needed.

[Gogoworks]

Update: After the daemon restarted, I can confirm the issue is specific to zhihu question, NOT a general bridge connectivity problem.

• opencli bilibili hot ✅ works
• opencli zhihu search "test" ✅ works
• opencli zhihu question 2021881398772981878 ❌ Not logged in

All tested in the same session with the same bridge connection. The earlier "Bridge not connected" errors were due to a daemon restart (PID changed from 80670 → 43950), which is now resolved.

So the bug is indeed isolated to zhihu question. The pre-navigation via resolvePreNav() may not be working correctly for this specific command, or the page.evaluate() fetch context loses the cookie after pre-nav. Happy to test any debug build if that helps.

$ opencli zhihu question 2021881398772981878 --limit 5 -v
🔒 Not logged in to www.zhihu.com
→ Please open Chrome and log in to https://www.zhihu.com

[Astro-Han]

Thanks for the additional verification. We have reproduced the reasoning gap on our side and the current diagnosis is now much clearer.

What we have confirmed:

• v1.5.6 matches the current repository code for src/clis/zhihu/question.ts and the browser pre-navigation path in src/execution.ts
• so this is not a release mismatch issue
• zhihu question currently collapses every non-OK response into AuthRequiredError, which is why different failures surface as the same misleading "Not logged in" message
• the problem is very likely in the adapter path itself, not in the generic Browser Bridge pre-navigation layer

At this point, this no longer looks like "just add one more goto()". It looks more like the current question adapter is relying on a brittle request path and has incorrect error classification.

We'll take this issue and work on a proper fix.

Planned direction:

1. fix the error classification so auth failure, anti-bot/risk-control, and unexpected API errors are not all reported as login failures
2. evaluate whether zhihu question should stop relying on the current direct API fetch path and switch to a more robust page-driven approach

No patch to propose yet in this comment, but we do agree there is a real bug here and we're taking ownership of the follow-up.

[Astro-Han]

A draft fix is up here:

• fix(zhihu): stop question command failing on unused detail fetch #606

What changed:

• zhihu question was fetching both question detail and answers in parallel
• only the answers response was actually used in the current CLI output
• the extra question detail request now returns 403 in a real logged-in Browser Bridge session, which caused the whole command to surface a misleading login failure
• the fix removes that unused detail request and keeps the command focused on the answers payload it already renders

I also verified the fix locally against a real Browser Bridge session, both through tsx and the built dist/main.js path.

Could you please test the branch / PR build with your original reproduction steps and confirm whether it resolves the issue on your side?

Suggested check:

opencli zhihu question 2021881398772981878 --limit 5 -f json

If you still see a failure, please paste the exact output and whether it happens with -v as well.