1. src/gateway/server-methods/channels.ts, line 431-495 (link)

   isConfigured called twice unnecessarily in buildChannelSummaryOnly

   When a channel plugin has both probeAccount and auditAccount, plugin.config.isConfigured(account, cfg) is awaited twice independently. If isConfigured has side effects or is expensive (e.g., a network call), this doubles the work. Consider computing it once and reusing the result before both blocks.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/gateway/server-methods/channels.ts
   Line: 431-495
   
   Comment:
   **`isConfigured` called twice unnecessarily in `buildChannelSummaryOnly`**
   
   When a channel plugin has both `probeAccount` and `auditAccount`, `plugin.config.isConfigured(account, cfg)` is awaited twice independently. If `isConfigured` has side effects or is expensive (e.g., a network call), this doubles the work. Consider computing it once and reusing the result before both blocks.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Keep the useful split, but fix the three remaining behavior regressions, add the required changelog entry, rebase on current main, and then rerun the targeted setup, channel-status, UI controller, typecheck, and lint lanes before merge.

Do we have a high-confidence way to reproduce the issue?

Yes. The remaining review issues are reproducible by deterministic code paths: run setup with a successful gateway probe, queue a stronger channel load and disconnect before finally, and use a channel plugin whose isConfigured is observable in summary-only probe mode.

Is this the best way to solve the issue?

No. The overall direction is maintainable, but the proposed branch is not the best final solution until it preserves the single-configuration-check guarantee, avoids stale UI pending state, guards the gateway note correctly, and records the user-facing changes in the changelog.

Full review comments:

• [P2] Clear pending channel refreshes after disconnect — ui/src/ui/controllers/channels.ts:171-180
  When a stronger request is queued during an in-flight load, this finally block only clears pending if the state is still connected with a client. If the UI disconnects first, the stale stronger request can replay after reconnect during an unrelated load, causing avoidable heavy status work and unexpected state replacement.
  Confidence: 0.87
• [P2] Gate missing-gateway guidance on failed probes — src/wizard/setup.finalize.ts:295-305
  This else is paired with if (!gatewayProbe.ok && installDaemon), so it also runs when the probe succeeds. Successful setup runs can therefore show Gateway not detected yet even though the Gateway is reachable; only show this note for the failed-probe/no-daemon case.
  Confidence: 0.9
• [P2] Reuse the configured result in summary snapshots — src/gateway/server-methods/channels.ts:347-354
  The summary-only path computes configured before probe/audit, but then calls buildChannelAccountSnapshot, whose default implementation can call plugin.config.isConfigured again for accounts without a configured field. That breaks the new lightweight status path's single configuration-check guarantee.
  Confidence: 0.8
• [P2] Add the required changelog entry — src/wizard/setup.ts:614-620
  This PR changes user-facing setup, OAuth, channel status, and Control UI behavior and is marked as both bug fix and feature work, but the diff has no CHANGELOG.md update. Repo policy requires a user-facing fix/feat change to include an active changelog entry with contributor credit before merge.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm test src/wizard/setup.finalize.test.ts src/gateway/server-methods/channels.status.test.ts ui/src/ui/controllers/channels.node.test.ts
• pnpm test src/daemon/schtasks.test.ts src/plugins/provider-openai-codex-oauth.test.ts src/wizard/setup.plugin-config.test.ts src/wizard/setup.test.ts ui/src/ui/app-settings.overview.node.test.ts ui/src/ui/app-settings.test.ts
• pnpm tsgo:prod
• pnpm check:test-types
• pnpm lint

What I checked:

• Current main lacks the new channel-status parameter: On current main, ChannelsStatusParamsSchema accepts probe and timeoutMs only; the PR's includeAccounts contract is branch-only work, not already implemented on main. (src/gateway/protocol/schema/channels.ts:230, 068b33de8717)
• Current main keeps setup TUI local and restores terminal state: Main already has the narrow terminal cleanup/local TUI behavior: setup launches launchTuiCli({ local: true }) inside a try/finally with pre/post restoreTerminalState, so that subset alone is not enough to close the PR as implemented. (src/wizard/setup.finalize.ts:454, 068b33de8717)
• PR head still shows missing-gateway guidance on successful probes: The PR head has an else paired only with if (!gatewayProbe.ok && installDaemon), so the 'Gateway not detected yet' note is also reachable when gatewayProbe.ok is true. (src/wizard/setup.finalize.ts:295, dcd1dc8b71a7)
• PR head still re-enters snapshot configuration checks: The PR computes configured before probe/audit, then calls buildChannelAccountSnapshot; the current helper can call plugin.config.isConfigured again when the account does not carry an inline configured field. (src/gateway/server-methods/channels.ts:347, dcd1dc8b71a7)
• PR head leaves queued refresh state behind on disconnect: The pending queued channel request is cleared only inside the connected/client branch, so disconnecting before finally finishes leaves privateState.pending available for a later unrelated load. (ui/src/ui/controllers/channels.ts:171, dcd1dc8b71a7)
• Prior review comments identify the same remaining blockers: The PR discussion includes review comments for clearing queued channel refreshes, guarding missing-gateway guidance, and avoiding duplicate summary configuration checks; the latest raw PR head still matches those code paths. (dcd1dc8b71a7)

Likely related people:

• steipete: Recent main history shows broad maintenance across the gateway channel-status path, onboarding health checks, provider OAuth prompts, and Windows task handling touched by this PR. (role: recent maintainer; confidence: high; commits: 526372ea36e3, 7f3f108521f4, 2d575bc00e90; files: src/gateway/server-methods/channels.ts, src/wizard/setup.finalize.ts, src/plugins/provider-oauth-flow.ts)
• BunsDev: Recent Control UI/channel controller commits updated channel state synchronization and operator-read handling, adjacent to the PR's loadChannels request coalescing changes. (role: adjacent UI owner; confidence: medium; commits: 245451b6a9c5, 3e2b3bd2c572; files: ui/src/ui/controllers/channels.ts, ui/src/ui/app-settings.ts)
• fuller-stack-dev: The local embedded TUI and setup hatch local-mode behavior appears to come from the merged local TUI work, which is directly affected by the PR's setup hatch changes. (role: introduced behavior; confidence: medium; commits: 276c00015c83; files: src/wizard/setup.finalize.ts, src/tui/tui-launch.ts, src/tui/gateway-chat.ts)
• shakkernerd: The setup TUI hatch terminal handoff and gateway-auth relaunch behavior was recently changed in this area, making this a relevant routing candidate for the setup/TUI slice. (role: introduced adjacent behavior; confidence: medium; commits: aae4b1b29dd7; files: src/wizard/setup.finalize.ts, src/tui/tui-launch.ts)
• Takhoffman: The channel-status state path was recently updated for auto-enable behavior in the same gateway status surface that the PR extends with summary-only responses. (role: adjacent owner; confidence: medium; commits: 0bcf07690137; files: src/gateway/server-methods/channels.ts)

Remaining risk / open question:

• The PR is XL and based on an older base SHA, so even after the discrete findings are fixed it still needs a rebase and touched-surface validation against current main.
• This review was read-only; I did not run the PR test matrix, so the assessment is based on source, public PR diff/API data, docs, and local main inspection.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 068b33de8717.