Codex App orchestrator for multiple accounts
CodexUse detects which Codex App window is running which account, shows live process state, and launches, focuses, stops, or restarts each window from the same place you manage your Codex CLI profiles.
The problem
Multi-account Codex workflows usually start in the CLI, because CODEX_HOME gives each profile its own auth and config. The Codex App adds a second surface: visual sessions, app-server state, and windows you expect to focus or restart like any other macOS process.
Once you run personal, work, and client accounts, the hard part is not saving auth. It is knowing which window belongs to which account, stopping the right one, and relaunching with the correct profile before a long task. Guess wrong and you burn a turn on the wrong quota.
Orchestrator, not just switcher
A switcher changes the active account. An orchestrator tracks the running surfaces attached to those accounts. CodexUse does both: profile-backed windows, live process state, direct controls, and thread handoff for the Codex App. On an account switch, it captures the current thread, waits for an active source turn to finish, resumes that thread through the target app-server, and continues the same conversation.
What Codex Apps orchestrates
- Launch: open the Codex App with a selected CodexUse profile.
- Detect: map already-open Codex App windows back to saved profiles when their account matches.
- Focus: bring the matched Codex app window forward.
- Stop: stop the matched macOS process tree.
- Restart: stop the matched window, then launch a fresh one with that profile.
- Live state: show running state, PID, app-server PID, and uptime.
- Continue: capture the current thread during an account switch and resume it through the target profile’s app-server.
How this fits with CLI profiles
Profiles stay local. Save each account once, switch from the tray, desktop app, or CLI, and keep contexts separate. Codex Apps extends that same profile layer to Codex App windows, so the window and the terminal agree on which account is active.
codexuse profile list
codexuse profile switch work
codexuse account-pool status
When to use Codex Apps vs Accounts Pool
| Need | Use |
|---|---|
| Open, monitor, or restart the Codex App under a specific account | Codex Apps |
| Switch the active Codex CLI profile before a terminal run | Profiles or CLI |
| Let another OpenAI-compatible tool share saved account quota | Accounts Pool |
| Run a non-OpenAI model in a Codex App window | Custom-provider profile |
| Move before an account runs out of usage | Rate-limit headroom and auto-roll |
Guardrails
- CodexUse does not create extra quota. It makes account state, switching, and routing explicit so you spend the quota you have on purpose.
- Stopping or restarting a window acts on the matched Codex App process tree.
- If a turn is active when a handoff starts, CodexUse waits for its completion event before it switches the profile.
- Thread handoff resumes a captured conversation. It does not clone provider-side session state or transfer an in-progress generation between accounts mid-turn.
- Accounts Pool is a local OpenAI-compatible API, not a hosted cloud service.
FAQ
Can the Codex App run with multiple accounts?
CodexUse can launch Codex App windows with profile-specific Codex homes, detect already-open profile-matched windows, and orchestrate focus, stop, restart, launch, and live process state from one local settings pane.
Does CodexUse require OpenAI API keys for Codex Apps?
Not for an OpenAI-account profile: CodexUse uses the same OAuth login model as Codex CLI. A custom-provider profile does need a credential for that provider, which CodexUse keeps in the macOS Keychain. Accounts Pool creates a separate local key only when another OpenAI-compatible client talks to CodexUse's local API.
Does Codex Apps hand off active tasks between accounts?
Yes, after the source turn is idle or complete. CodexUse captures the current thread, reopens it through the target profile’s app-server, and continues the same conversation. It does not transfer an in-progress generation mid-turn.