jackwener/opencli

现在应该已经支持了。

> [@haoyan-yam](https://github.com/haoyan-yam) 这张截图很关键，说明问题不只是 `MP_WXS_*` 公众号条目，普通书 `22920382` 也一样失败。
>
> 当前问题更像是：`weread shelf` 还能通过网页缓存列出书架，但 `weread book` 在私有 API 失效后的详情回退链路，而不只是某一种书籍类型。
>
> 如果你方便，麻烦帮我补这几条完整输出：
>
> 1. `opencli weread book 22920382 -f json -v`
> 2. `opencli weread book MP_WXS_3634777637 -f json -v`
> 3. `opencli weread shelf --limit 10 -f json`
>
> 有了这几条，我就能判断问题到底是卡在：
>
> * 私有 API 认证
> * 书架缓存到 reader URL 的映射
> * 还是 reader 页面本身的详情提取

@haoyan-yam 这张截图很关键，说明问题不只是 `MP_WXS_*` 公众号条目，普通书 `22920382` 也一样失败。

当前问题更像是：`weread shelf` 还能通过网页缓存列出书架，但 `weread book` 在私有 API 失效后的详情回退链路，而不只是某一种书籍类型。

如果你方便，麻烦帮我补这几条完整输出：

1. `opencli weread book 22920382 -f json -v`
2. `opencli weread book MP_WXS_3634777637 -f json -v`
3. `opencli weread shelf --limit 10 -f json`

有了这几条，我就能判断问题到底是卡在：
- 私有 API 认证
- 书架缓存到 reader URL 的映射
- 还是 reader 页面本身的详情提取

> 继续排查后，结论更新一下：
>
> 目前看，这个问题主要集中在 `MP_WXS_*` 这类公众号条目，不像是单纯的登录失效。
>
> 现在 `weread shelf` 还能显示，是因为私有 API 失效后会回退到网页本地缓存；但 `weread book` 打开详情时走的是另一套更严格的兜底逻辑。
>
> 我这边进一步验证后发现，普通书籍在同样的状态下是可以正常打开详情的，所以范围已经基本缩小到这类公众号条目的兼容问题。也就是说，当前版本里，公众号类型书籍很可能还不能像普通书那样稳定访问详情，这更像是 opencli 的适配缺口，不是你本地没有登录。
>
> 这个方向看起来是可以继续修的。如果你方便的话，也欢迎帮忙再确认一下：书架里如果挑一个普通数字 `bookId` 的书，运行 `opencli weread book ` 是否能成功；如果普通书可以、`MP_WXS_*` 不行，就能进一步坐实这个判断。

普通的 book 还是一样显示没有登录，不是公众号的问题：

继续排查后，结论更新一下：

目前看，这个问题主要集中在 `MP_WXS_*` 这类公众号条目，不像是单纯的登录失效。

现在 `weread shelf` 还能显示，是因为私有 API 失效后会回退到网页本地缓存；但 `weread book` 打开详情时走的是另一套更严格的兜底逻辑。

我这边进一步验证后发现，普通书籍在同样的状态下是可以正常打开详情的，所以范围已经基本缩小到这类公众号条目的兼容问题。也就是说，当前版本里，公众号类型书籍很可能还不能像普通书那样稳定访问详情，这更像是 opencli 的适配缺口，不是你本地没有登录。

这个方向看起来是可以继续修的。如果你方便的话，也欢迎帮忙再确认一下：书架里如果挑一个普通数字 `bookId` 的书，运行 `opencli weread book ` 是否能成功；如果普通书可以、`MP_WXS_*` 不行，就能进一步坐实这个判断。

收到 bug 反馈，我先尝试复现。

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.

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...

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
```

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 "...

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...

Try #475 .

Option 1 could currently be addressed by just using symlink your plugin code into `~/.opencli/plugins/`.

Thanks for your advice. Actually plugin manifests is what we're currently designing, coming soon~.

Nice work! The approach of extracting `access_token` from the live session and hitting VK's internal API is clever — best of both worlds.

If you'd like to get it listed in the README plugin table, a one-line PR adding it [here](https://github.com/jackwener/opencli/blob/main/README.md#plugins) would do it. Happy to review.