### Summary Fix `thread/metadata/update` so it can still patch stored thread metadata when the list/backfill-gated `get_state_db(...)` path is unavailable. What was happening: - The app logs showed `thread/metadata/update` failing with `sqlite state db unavailable for thread ...`. - This was not isolated to one bad thread. Once the failure started for a user, branch metadata updates failed 100% of the time for that user. - Reports were staggered across users, which points at local app-server / local SQLite state rather than one global server-side failure. - Turns could still start immediately after the metadata update failed, which suggests the thread itself was valid and the failure was in the metadata endpoint DB-handle path. The fix: - Keep using the loaded thread state DB and the normal `get_state_db(...)` fallback first. - If that still returns `None`, open `StateRuntime::init(...)` directly for this targeted metadata update path. - Log the direct state runtime init error if that final fallback also fails, so future reports have the real DB-open cause instead of only the generic unavailable error. - Add a regression test where the DB exists but backfill is not complete, and verify `thread/metadata/update` can still repair the stored rollout thread and patch `gitInfo`. Relevant context / suspect PRs: - #16434 changed state DB startup to run auto-vacuum / incremental vacuum. This is the most suspicious timing match for per-user, staggered local SQLite availability failures. - #16433 dropped the old log table from the state DB, also near the timing window. - #13280 introduced this endpoint and made it rely on SQLite for git metadata without resuming the thread. - #14859 and #14888 added/consumed persisted model + reasoning effort metadata. I checked these because of the new thread metadata fields, but this failure happens before the endpoint reaches thread-row update/load logic, so they seem less likely as the direct cause. ### Testing - `cargo fmt -- --config imports_granularity=Item` completed; local stable rustfmt emitted warnings that `imports_granularity` is unstable - `cargo test -p codex-app-server thread_metadata_update` - `git diff --check`
npm i -g @openai/codex
or brew install --cask codex
Codex CLI is a coding agent from OpenAI that runs locally on your computer.
If you want Codex in your code editor (VS Code, Cursor, Windsurf), install in your IDE.
If you want the desktop app experience, run
codex app or visit the Codex App page.
If you are looking for the cloud-based agent from OpenAI, Codex Web, go to chatgpt.com/codex.
Quickstart
Installing and running Codex CLI
Install globally with your preferred package manager:
# Install using npm
npm install -g @openai/codex
# Install using Homebrew
brew install --cask codex
Then simply run codex to get started.
You can also go to the latest GitHub Release and download the appropriate binary for your platform.
Each GitHub Release contains many executables, but in practice, you likely want one of these:
- macOS
- Apple Silicon/arm64:
codex-aarch64-apple-darwin.tar.gz - x86_64 (older Mac hardware):
codex-x86_64-apple-darwin.tar.gz
- Apple Silicon/arm64:
- Linux
- x86_64:
codex-x86_64-unknown-linux-musl.tar.gz - arm64:
codex-aarch64-unknown-linux-musl.tar.gz
- x86_64:
Each archive contains a single entry with the platform baked into the name (e.g., codex-x86_64-unknown-linux-musl), so you likely want to rename it to codex after extracting it.
Using Codex with your ChatGPT plan
Run codex and select Sign in with ChatGPT. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Team, Edu, or Enterprise plan. Learn more about what's included in your ChatGPT plan.
You can also use Codex with an API key, but this requires additional setup.
Docs
This repository is licensed under the Apache-2.0 License.
