jlcodes99/cockpit-tools · warning

[Codex Store] 自动恢复接管失败:

Error message

[Codex Store] 自动恢复接管失败:

What it means

In useCodexAccountStore, the restoreActiveTakeoverIfNeeded action calls codexService.restoreCodexActiveTakeoverIfEnabled() on startup to re-attach the previously active Codex account takeover (proxy/session hijacking of the CLI config). Any exception thrown by the Tauri backend or service layer is caught and only logged as a warning, so app startup is never blocked — but the active takeover silently fails to be restored.

Source

Thrown at src/stores/useCodexAccountStore.ts:216

      const currentAccount = await codexService.getCurrentCodexAccount();
      if (requestId !== fetchCodexCurrentAccountSeq) {
        return;
      }
      set({ currentAccount });
      persistCodexCurrentAccountCache(currentAccount);
    } catch (e) {
      if (requestId !== fetchCodexCurrentAccountSeq) {
        return;
      }
      console.error('获取当前 Codex 账号失败:', e);
    }
  },

  restoreActiveTakeoverIfNeeded: async () => {
    try {
      await codexService.restoreCodexActiveTakeoverIfEnabled();
    } catch (e) {
      console.warn('[Codex Store] 自动恢复接管失败:', e);
    }
  },

  applyAccountSnapshot: (account: CodexAccount) => {
    if (!account?.id) return;

    // 授权/切号返回的账号是后端刚落盘的权威快照,先写入内存和 localStorage,
    // 同时使旧的异步回读失效,避免旧结果把刚更新的状态覆盖回去。
    invalidateCodexFetchRequests();
    set((state) => {
      const nextAccounts = mergeCodexAccountIntoList(state.accounts, account);
      const nextCurrentAccount =
        state.currentAccount?.id === account.id ? account : state.currentAccount;
      persistCodexAccountsCache(nextAccounts);
      persistCodexCurrentAccountCache(nextCurrentAccount);
      return {
        accounts: nextAccounts,
        currentAccount: nextCurrentAccount,

View on GitHub (pinned to 1ed8b77992)

Solutions

  1. Inspect the logged error object `e` in the console to see the underlying Tauri/backend cause (file permission, missing config, IPC failure).
  2. Verify the Codex config file path exists and is writable by the app (check permissions / antivirus lock).
  3. Clear stale takeover state in the backend store so restore starts from a clean slate, then re-enable takeover manually.
  4. If it persists after an app update, confirm the Tauri command name restore_codex_active_takeover_if_enabled still matches the frontend invoke call.

Example fix

// before
try {
  await codexService.restoreCodexActiveTakeoverIfEnabled();
} catch (e) {
  console.warn('[Codex Store] 自动恢复接管失败:', e);
}
// after
try {
  await codexService.restoreCodexActiveTakeoverIfEnabled();
} catch (e) {
  console.warn('[Codex Store] 自动恢复接管失败:', e);
  get().refreshAccounts?.(); // resync so UI reflects that takeover is NOT active
}
Defensive patterns

Strategy: try-catch

Validate before calling

// before restoring, check state availability
const enabled = await codexService.isCodexTakeoverEnabled?.();
if (!enabled) return; // nothing to restore

Type guard

function isTakeoverResult(v: unknown): v is { restored: boolean } {
  return !!v && typeof v === 'object' && 'restored' in v;
}

Try / catch

try {
  await codexService.restoreCodexActiveTakeoverIfEnabled();
} catch (e) {
  console.warn('[Codex Store] 自动恢复接管失败:', e);
  // mark takeover state as inactive in UI so users can re-enable manually
}

Prevention

When it happens

Trigger: App startup or store initialization when restoreCodexActiveTakeoverIfEnabled() throws: Tauri IPC invoke fails, the backend cannot read/write Codex config.toml, or no enabled takeover record exists but the backend treats that as an error.

Common situations: Codex CLI config file missing or permissions-restricted, stale takeover state pointing at a removed account, Tauri backend command renamed/panicking after an update, or the app started before the Codex home directory existed.

Related errors


AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05). Data as JSON: /api/errors/c14d692d75fde89c. Report an issue: GitHub.