Market Trends
GitHub Issue
zhihu question command fails with 'Not logged in' despite valid session
## Bug Description
`opencli zhihu question ` 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:
```typescript
await page.goto('https://www.zhihu.com');
```
This matches the pattern used in `search.yaml` and should allow `credentials: 'include'` to work correctly.
View Raw Thread
Developer & User Discourse
Gogoworks • Mar 30, 2026
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 "...
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 "...
Gogoworks • Mar 30, 2026
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
```
- `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 • Mar 30, 2026
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...
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...
Astro-Han • Mar 30, 2026
A draft fix is up here:
- #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:
```bash
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.
- #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:
```bash
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.
`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...