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
- Inspect the logged error object `e` in the console to see the underlying Tauri/backend cause (file permission, missing config, IPC failure).
- Verify the Codex config file path exists and is writable by the app (check permissions / antivirus lock).
- Clear stale takeover state in the backend store so restore starts from a clean slate, then re-enable takeover manually.
- 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
- Ensure the Codex config directory exists and is writable before app startup restore
- Clean up stale takeover records when an account is deleted
- Surface restore failure in the UI instead of only console.warn so users know to re-enable takeover
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
- 加载 Codex API 服务速度失败:
- 刷新 Codex 配额失败
- [account-sync] Failed to emit ${eventName}:
- [account-sync] Failed to emit ${ACTIVE_PLATFORM_FOCUS_EVENT}
- [ExternalImport] 读取待处理导入请求失败:
AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05).
Data as JSON: /api/errors/c14d692d75fde89c.
Report an issue: GitHub.