[Bug]: opencli boss 内置api调用一次，boss直聘网站马上强制下线跳到登录页，登录态无法保存

[jack-930608]

Description

opencli chrome扩展都正常连接，但是使用opencli boss命令调用一次之后，boss账号马上下线，跳转到登陆页，感觉是触发了风控，为什么才调用一次就被boss发现了

Steps to Reproduce

1. Run opencli ...
2. ...
3. See error

Expected Behavior

希望正常使用使用opencli boss命令调用api功能，不需要重新登录

OpenCLI Version

1.7.3

Node.js Version

20.x

Operating System

macOS

Logs / Screenshots

[Astro-Han]

Could you share the exact opencli boss ... command, whether this happens on the first request after a fresh login every time, and whether it affects one subcommand or all BOSS commands?

If you can, please also include output from OPENCLI_DIAGNOSTIC=1.

[jack-930608]

执行的命令opencli boss chatlist 和 opencli boss stats，都是每次新登录之后，执行其中任何一句opencli boss的功能命令，都是正常返回了需要展示的数据，但是chrome上boss直聘马上丢失登陆态，所以第二次执行相关opencli boss指令就会告诉你未登录，而且我试了opencli bilibili的功能命令是不会出现丢失登陆态的情况

[Astro-Han]

Thanks for the follow-up. This is much clearer now.

The important detail is that opencli boss chatlist and opencli boss stats both return valid data first, and then the BOSS web session is invalidated immediately in Chrome. That makes this look less like a generic login problem and more like the current browser-authenticated request path is tripping BOSS risk control.

The fact that bilibili does not do this points the same way. The extension and session reuse are probably not the root cause.

[jack-930608]

请问有什么思路或者方法可以排查并解决这种问题吗 目前问题的难点就是登录态无法长期保存

[Astro-Han]

A reasonable way to narrow this down is:

1. Run OPENCLI_DIAGNOSTIC=1 opencli boss chatlist -f json and OPENCLI_DIAGNOSTIC=1 opencli boss stats -f json.
2. Check whether the logout happens immediately after the API request returns, or after a follow-up navigation.
3. In Chrome DevTools, compare one normal BOSS request made by the site itself with the request OpenCLI triggers. The main things to compare are request headers, referrer, and whether any anti-bot or session fields are missing.
4. Check whether specific cookies disappear or change right after the command runs.

From the current behavior, my guess is that the request path is triggering BOSS risk control, not that Chrome login reuse is broken in general.