openUrl throw not caught — fallback only handles false return

createVpsAwareOAuthHandlers falls back to manual entry only when openUrl returns exactly false. If an openUrl implementation throws instead (which extensions/minimax/oauth.ts guards against with a try/catch around the same call), the exception propagates out of onAuth and aborts the OAuth flow with no graceful recovery. Given the PR intent is to "add safer OAuth browser-open fallback behavior and align provider openUrl contracts", consider adding a try/catch here too:

let opened: unknown;
try {
  opened = await params.openUrl(url);
} catch {
  opened = false;
}
if (opened === false) {
  // ... existing fallback
}

This is a comment left during a code review.
Path: src/plugins/provider-oauth-flow.ts
Line: 41-50

Comment:
**`openUrl` throw not caught — fallback only handles `false` return**

`createVpsAwareOAuthHandlers` falls back to manual entry only when `openUrl` returns exactly `false`. If an `openUrl` implementation throws instead (which `extensions/minimax/oauth.ts` guards against with a try/catch around the same call), the exception propagates out of `onAuth` and aborts the OAuth flow with no graceful recovery. Given the PR intent is to "add safer OAuth browser-open fallback behavior and align provider `openUrl` contracts", consider adding a try/catch here too:

```ts
let opened: unknown;
try {
  opened = await params.openUrl(url);
} catch {
  opened = false;
}
if (opened === false) {
  // ... existing fallback
}
```

How can I resolve this? If you propose a fix, please make it concise.

Treat a successful gateway probe as a success path

When waitForGatewayReachable succeeds (gatewayProbe.ok === true), this condition falls through to the else branch and still shows the "Gateway not detected yet" note. That means normal successful onboarding with --skip-health off now reports a false negative to users, which is confusing and can trigger unnecessary troubleshooting even though the gateway is reachable.

Useful? React with 👍 / 👎.

Keep setup TUI out of the onboarding process

Calling runTui(...) here makes the onboarding flow non-returning for the TUI path: runTui drives its own lifecycle and exits the process (process.exit(0)) when the user leaves TUI, so control never reliably returns to finish the remaining setup steps in this function (shell completion, final notes/outro, and clean finalize behavior). This is a regression from the previous child-process launch behavior and affects any user choosing “Hatch in TUI”.

Useful? React with 👍 / 👎.

Treat undefined browser-open result as open failure

The new fallback only triggers when openUrl returns false, but several auth call paths pass wrappers that await openUrl(url) without returning its boolean (src/plugins/provider-auth-choice.ts:143 and src/commands/models/auth.ts:303), so opened becomes undefined and this branch is skipped even when browser launch fails. In local/headless environments this regresses the intended manual OAuth fallback and leaves users without the immediate paste-redirect prompt.

Useful? React with 👍 / 👎.

Avoid passing gateway secrets through TUI argv

This onboarding path now forwards the gateway token/password directly into launchTuiCli, which turns them into --token/--password command-line args (src/tui/tui-launch.ts). On multi-user systems (or any environment where process args are inspectable/logged), that exposes live gateway credentials in plaintext via process listings and telemetry. The previous config-auth launch path avoided argv secret exposure, so this is a security regression for users choosing “Hatch in TUI”.

Useful? React with 👍 / 👎.

Preserve env setup when skipping batch control-flow lines

Do not unconditionally skip if/for lines here, because readScheduledTaskCommand then drops environment assignments performed inside control-flow wrappers (for example loading OPENCLAW_GATEWAY_TOKEN from a .env loop). In the fallback path, launchFallbackTaskScript uses the parsed programArguments directly, so that skipped setup block is never executed by cmd.exe, and the relaunched gateway can start without required auth/env values.

Useful? React with 👍 / 👎.

Preserve activity/probe fields in summary-only channel snapshots

The new includeAccounts: false path builds snapshot directly with buildChannelAccountSnapshot, which skips the extra enrichment done in buildAccountSnapshot (notably lastProbeAt and getChannelActivity fallbacks for lastInboundAt/lastOutboundAt). As a result, channels.status can now return different channel summaries depending on includeAccounts, and summary builders that read those fields (for example WhatsApp’s buildChannelSummary using snapshot.lastInboundAt) can regress to null/stale values in overview requests even when recent activity exists.

Useful? React with 👍 / 👎.

Restore terminal state after failed TUI hatch

This branch now calls launchTuiCli(...) without a post-launch cleanup, so if the TUI exits non-zero (or via signal) onboarding throws before restoring terminal modes. In that failure path, launchTuiCli only resumes stdin, which can leave raw mode/TTY state dirty and break the user’s shell session after onboarding aborts. Please add a guaranteed terminal restore on the error path (e.g., a finally around the launch call).

Useful? React with 👍 / 👎.

Clear one-shot TUI auth env vars after reading

The new launch auth handoff reads OPENCLAW_TUI_LAUNCH_GATEWAY_TOKEN/PASSWORD from process.env, but never scrubs them. That leaves live gateway credentials in the TUI process environment for the entire session, so plugin/tool code and spawned child processes can inherit or inspect them; this is a credential exposure regression, especially when setup resolved a password SecretRef just for bootstrapping TUI auth. These env vars should be deleted immediately after extracting their values.

Useful? React with 👍 / 👎.

Omit default includeAccounts from channels.status requests

Avoid always sending includeAccounts here: when this UI talks to an older gateway that still validates channels.status params without that field (with additionalProperties: false), the request is rejected as invalid and channel status fails entirely. This only needs to be sent for the non-default optimization path (includeAccounts: false), so omitting it when true preserves backward compatibility for mixed-version dashboard/gateway setups.

Useful? React with 👍 / 👎.

Retry channels overview fetch without includeAccounts flag

The overview path now always calls loadChannels(..., { includeAccounts: false }), which sends a new request field that older gateways do not understand. In mixed-version setups (new UI bundle against an older gateway), this causes channels.status to fail on every overview refresh even though the legacy request shape would succeed; loadChannels currently surfaces the error instead of falling back. Add a compatibility retry that reissues the request without includeAccounts when the gateway rejects unknown params.

Useful? React with 👍 / 👎.

Build summary-only channel status from an effective account

The summary-only path resolves and probes only defaultAccountId directly, but that id can be stale/missing in config. The full-account path explicitly falls back to the first available account snapshot, while this new lightweight path does not, so includeAccounts: false responses can report a channel as unconfigured/offline even when another account is active. Mirror the full-path fallback before building/probing the summary snapshot.

Useful? React with 👍 / 👎.

Keep start/logout default account resolution aligned

channels.status now rewrites stale defaults to the first live account via resolveEffectiveDefaultAccountId, so the payload can advertise channelDefaultAccountId as a different account than config. However, channels.start/channels.logout still resolve omitted accountId through resolveChannelGatewayAccountId (which prefers the stale configured default first), so clients that omit accountId can now act on a different account than the one status reports and hit avoidable start/logout failures when the configured default is stale.

Useful? React with 👍 / 👎.