[squarepots]

What changed

Update in the Codex CLI dialog now waits for GSwitch's own operation lock instead of failing at once. While a quota refresh or another GSwitch operation holds the lock, the update waits for it to finish, then runs codex update with the lock held and the existing external-Codex check. The unreachable CLI busy failure code and its two strings are removed. docs/security.md records the waiting behavior.

Why

The maintainer reported "Another GSwitch operation is in progress" when they clicked Update without starting anything else. Their screenshot shows Refreshing x/5 in the toolbar. Quota refreshes do not set the UI's busy state, so Update stayed enabled. The backend used a non-waiting try-lock, so the update collided with a refresh's short quota commit or with an expired saved sign-in's official token refresh, which holds the lock while App Server runs.

Every in-process lock holder is bounded by existing HTTP (20 s) and App Server (15 s start, 30 s request) timeouts, and the single-instance plugin rules out a second GSwitch process. Wake keeps its own non-dismissible dialog over the window while it runs, so the CLI dialog cannot be opened behind it. No UI gate was needed.

Validation

• A new Rust regression test holds the operation lock on one thread and checks that the CLI update acquisition waits and then succeeds after release. Run against the old try-lock implementation, it failed as expected.
• cargo fmt --check, cargo clippy --all-targets -- -D warnings, and the full Rust suite (177 passed, 1 ignored) passed on Windows.
• 157 frontend tests passed with pnpm test --exclude '.claude/**'; pnpm build, pnpm run version:check, and git diff --check passed.

Remaining

The real codex update was not run against the maintainer's installed CLI. No credentials, account state, provider protocol, or version files change.