fix(desktop): stop claiming "Connected" — desktop QQ is config-editor-only (#1317)#1326
Merged
Conversation
… only #1241 added the desktop QQ settings UI but never wired up an actual QQChannel — pressing "Connect" only flipped `cfg.qq.enabled = true` and emitted a "QQ enabled" status, while the channel itself can only run inside the CLI (chat.tsx auto-starts it on launch based on the same flag). The UI then displayed "Connected" / "已连接" because the desktop helper returned `connected: configured && enabled`. That conflated "config flag on" with "live channel up" — which is the root cause of #1317: the user saw "successfully connected", the access control panel said "unbound" (no first-sender binding could happen — no bot was running), and the bot didn't respond. This PR makes the desktop honest: - `loadDesktopQQState` always returns `connected: false` (the desktop process never holds a QQChannel) and adds `enabledForCli: boolean` to surface the actual flag-state for the UI. - New labels: "Enabled (CLI)" / "Configured · disabled" / "Not configured" replace the binary "Connected / Disconnected" lie. - New `qqRuntimeNote` banner explains that the bot runs in `reasonix` terminal sessions, not in the desktop window. Credentials saved here are picked up by the next CLI launch. - Button labels: "Connect" → "Enable for CLI", "Disconnect" → "Disable". - Status text emitted by `qq_connect` / `qq_disconnect` tells the user to run `reasonix` in a terminal instead of implying the desktop is now the runtime. - Protocol back-compat: `connected` field stays in the event shape (always false) so older desktop clients don't crash. Tests: `desktop-qq-config` adds two new assertions (#1317 regressions) that `connected` is always false and `enabledForCli` reflects the real state. `desktop-qq-settings-ui` updates the zh-CN label test to match the new "Not configured" label and adds coverage for the new "Enabled (CLI)" and "Configured · disabled" states. The "Desktop runs its own QQChannel" feature stays as a future enhancement — it needs lifecycle work (which tab owns the channel? how does the desktop runtime route incoming messages? what about the `~/.reasonix/qq-channel.pid` lock racing the CLI?) and isn't required to fix the immediate lying-status bug. Closes #1317
ChasLui
pushed a commit
to ChasLui/DeepSeek-Reasonix
that referenced
this pull request
May 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
#1241 added a QQ settings entry to the desktop app, but the wiring only flips
cfg.qq.enabled = trueand emits a status — it never starts an actual QQChannel in the desktop process. The channel only ever runs in the CLI (chat.tsxauto-starts it on launch based on the same flag).The desktop UI then displayed "Connected" / "已连接" because
loadDesktopQQStatereturnedconnected: configured && enabled. That conflated "config flag on" with "live channel up" — and that's the root cause of #1317:Fix
Stop lying. Don't pretend the desktop is the runtime when it's only the config editor.
loadDesktopQQStatealways returnsconnected: false. Adds a newenabledForCli: booleanfield reflecting "credentials saved AND toggle on — nextreasonixterminal session will start the bot."qqRuntimeNotebanner above the QQ section explains the runtime split.qq_connect/qq_disconnecttells the user to runreasonixin a terminal instead of implying the desktop is now the runtime.connectedstays in theQQSettingsEventshape (always false) so older clients don't crash.The bigger architectural lift — making the desktop process actually host a QQChannel — stays as a future enhancement. It needs lifecycle work (which tab owns the channel? how does the desktop runtime route incoming messages back to a specific tab? what about the
~/.reasonix/qq-channel.pidlock racing the CLI?) and isn't required to fix the immediate user-visible lying-status bug.Test plan
npm run verify— 231 test files / 3,249 tests passtests/desktop-qq-config.test.ts— adds two /qq命令不存在；设置显示成功连接QQ通道，访问控制未绑定；无法使用QQ机器人 #1317 regression tests (connectedis always false,enabledForClireflects real state)tests/desktop-qq-settings-ui.test.ts— updates the zh-CN label test for "未配置" and adds coverage for "Enabled (CLI)" + "Configured · disabled"npm run lintcleannpm run typecheckclean