3 Commits

• runtime: detect Codex package layout (#23596)

  ## Why
  
  The package-builder stack now creates a canonical Codex package
  directory where the entrypoint lives under `bin/`, bundled helper
  resources live under `codex-resources/`, and bundled PATH-style tools
  live under `codex-path/`. That layout is not specific to the standalone
  installer: npm, brew, install scripts, and manually unpacked artifacts
  should all be able to use the same package shape.
  
  The Rust runtime still only knew about the legacy standalone release
  layout, where resources sit next to the executable. A packaged binary
  therefore would not identify its package root or prefer the bundled `rg`
  from `codex-path/`.
  
  ## What changed
  
  - Adds `CodexPackageLayout` to `codex-install-context` and detects it
  from an executable path shaped like `<package>/bin/<entrypoint>` when
  `<package>/codex-package.json` is present.
  - Splits `InstallContext` into an install `method` plus an optional
  package layout so the layout is shared across npm, bun, brew,
  standalone, and other launch contexts.
  - Stores package-layout paths as `AbsolutePathBuf` values.
  - Keeps `codex-resources/` and `codex-path/` optional so Codex can still
  run with degraded behavior if sidecar directories are missing.
  - Updates `InstallContext::rg_command()` to prefer bundled
  `codex-path/rg` or `rg.exe`, then fall back to the legacy standalone
  resources location, then system `rg`.
  - Updates `codex doctor` reporting so package installs show package,
  bin, resources, and path directories, and so bundled search detection
  recognizes `codex-path/` for any install method.
  
  ## Test plan
  
  - `cargo test -p codex-install-context`
  - `cargo test -p codex-cli`
  - `cargo test -p codex-tui
  update_action::tests::maps_install_context_to_update_action`
  - `just bazel-lock-check`

  Michael Bolin · 2026-05-19 23:13:49 -07:00
  cfa16fcc2e
• feat: dedicated goal DB (#23300)

  ## Why
  
  Thread goals are moving toward extension-owned runtime behavior, but
  their persisted state was still stored in the shared state database.
  This makes the goal store harder to isolate and keeps future storage
  splits tied to ad hoc runtime plumbing.
  
  This PR gives goals their own SQLite database while keeping the existing
  `StateRuntime` entry point. The goal is to make this the pattern for
  adding more dedicated runtime databases later.
  
  This also reduce load on existing DB and reduce contention
  
  ## Limitation
  Thread preview from goal is not supported anymore. I'm looking into this
  [EDIT]: solved
  
  ## What changed
  
  - Added a dedicated `goals_1.sqlite` database with its own
  `goals_migrations` directory.
  - Moved `thread_goals` creation into the goals DB migration set.
  - Dropped the old `thread_goals` table from the main state DB with a
  normal state migration. There is intentionally no backfill for existing
  goal rows.
  - Changed `GoalStore` to be backed only by the goals DB pool.
  - Removed the old goal-write side effect that filled empty
  `threads.preview` values from the goal objective.
  - Added shared runtime DB path metadata so startup, telemetry, `codex
  doctor`, and repair handling can include future DBs without bespoke path
  lists.
  - Updated Bazel compile data so the new goals migration directory is
  available to `sqlx::migrate!`.
  
  ## Verification
  
  - `cargo check --tests -p codex-state -p codex-cli -p codex-core -p
  codex-app-server`
  - `just fix -p codex-state`
  - `just fix -p codex-cli`
  - `just fix -p codex-app-server`

  jif-oai · 2026-05-19 11:11:41 +02:00
  ba57aab13a
• feat(cli): add codex doctor diagnostics (#22336)

  ## Why
  
  Users and support need a single command that captures the local Codex
  runtime, configuration, auth, terminal, network, and state shape without
  asking the user to know which diagnostic depth to choose first. `codex
  doctor` now runs the useful checks by default and makes the detailed
  human output the default because the command is usually run when someone
  already needs context.
  
  The command also targets concrete support failure modes we have seen
  while iterating on the design:
  
  - update-target mismatches like #21956, where the installed package
  manager target can differ from the running executable
  - terminal and multiplexer issues that depend on `TERM`, tmux/zellij
  state, color handling, and TTY metadata
  - provider-specific HTTP/WebSocket connectivity, including ChatGPT
  WebSocket handshakes and API-key/provider endpoint reachability
  - local state/log SQLite integrity problems and large rollout
  directories
  - feedback reports that need an attached, redacted diagnostic snapshot
  without asking the user to run a second command
  
  ## What Changed
  
  - Adds `codex doctor` as a grouped CLI diagnostic report with default
  detailed output and `--summary` for the compact view.
  - Adds stable report sections for Environment, Configuration, Updates,
  Connectivity, and Background Server, plus a top Notes block that
  promotes anomalies such as available updates, large rollout directories,
  optional MCP issues, and mixed auth signals.
  - Adds runtime provenance, install consistency, bundled/system search
  readiness, terminal/multiplexer metadata, `config.toml` parse status,
  auth mode details, sandbox details, feature flag summaries, update
  cache/latest-version state, app-server daemon state, SQLite integrity
  checks, rollout statistics, and provider-aware network diagnostics.
  - Adds ChatGPT WebSocket diagnostics that report the negotiated HTTP
  upgrade as `HTTP 101 Switching Protocols` and include timeout, DNS,
  auth, and provider context in detailed output.
  - Makes reachability provider-aware: API-key OpenAI setups check the API
  endpoint, ChatGPT auth checks the ChatGPT path, and custom/AWS/local
  providers check configured HTTP endpoints when available.
  - Adds structured, redacted JSON output where `checks` is keyed by check
  id and `details` is a key/value object for support tooling.
  - Integrates doctor with feedback uploads by attaching a best-effort
  `codex-doctor-report.json` report and adding derived Sentry tags for
  overall status and failing/warning checks.
  - Updates the TUI feedback consent copy so users can see that the doctor
  report is included when logs/diagnostics are uploaded.
  - Updates the CLI bug issue template to ask reporters for `codex doctor
  --json` and render pasted reports as JSON.
  
  ## Example Output
  
  The examples below are sanitized from local smoke runs with `--no-color`
  so the structure is reviewable in plain text.
  
  ### `codex doctor`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
        version                  0.0.0
        install method           other
        commit                   unknown
        executable               ~/code/codex.fcoury-doct…x-rs/target/debug/codex
    ✓ install      consistent
        context                  other
        managed by               npm: no · bun: no · package root —
        PATH entries (2)         ~/.local/share/mise/installs/node/24/bin/codex
                                 ~/.local/share/mise/shims/codex
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
        terminal                 Ghostty
        TERM_PROGRAM             ghostty
        terminal version         1.3.2-main-+b0f827665
        TERM                     xterm-256color
        multiplexer              tmux 3.6a
        tmux extended-keys       on
        tmux allow-passthrough   on
        tmux set-clipboard       on
    ✓ state        databases healthy
        CODEX_HOME               ~/.codex (dir)
        state DB                 ~/.codex/state_5.sqlite (file) · integrity ok
        log DB                   ~/.codex/logs_2.sqlite (file) · integrity ok
        active rollouts          1,526 files · 2.53 GB (avg 1.70 MB)
        archived rollouts        8 files · 3.84 MB (avg 491.11 KB)
  
  Configuration
    ✓ config       loaded
        model                    gpt-5.5 · openai
        cwd                      ~/code/codex.fcoury-doctor/codex-rs
        config.toml              ~/.codex/config.toml
        config.toml parse        ok
        MCP servers              1
        feature flags            36 enabled · 7 overridden (full list with --all)
        overrides                code_mode, code_mode_only, memories, chronicle, goals, remote_control, prevent_idle_sleep
    ✓ auth         auth is configured
        auth storage mode        File
        auth file                ~/.codex/auth.json
        auth env vars present    OPENAI_API_KEY
        stored auth mode         chatgpt
        stored API key           false
        stored ChatGPT tokens    true
        stored agent identity    false
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
        configured servers       1
        disabled servers         0
        streamable_http servers  1
        optional reachability    openaiDeveloperDocs: https://developers.openai.com/mcp (HEAD connect failed; GET connect failed)
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
        approval policy          OnRequest
        filesystem sandbox       restricted
        network sandbox          restricted
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
        model provider           openai
        provider name            OpenAI
        wire API                 responses
        supports websockets      true
        connect timeout          15000 ms
        auth mode                chatgpt
        endpoint                 wss://chatgpt.com/backend-api/<redacted>
        DNS                      2 IPv4, 2 IPv6, first IPv6
        handshake result         HTTP 101 Switching Protocols
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
        reachability mode        API key auth
        openai API               https://api.openai.com/v1 connect failed (required)
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  --summary compact output           --all expand truncated lists
  --json redacted report
  ```
  
  ### `codex doctor --summary`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
    ✓ install      consistent
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
    ✓ state        databases healthy
  
  Configuration
    ✓ config       loaded
    ✓ auth         auth is configured
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
  
  Updates
    ✓ updates      update configuration is locally consistent
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  Run codex doctor without --summary for detailed diagnostics.
  --all expand truncated lists       --json redacted report
  ```
  
  ### `codex doctor --json` shape
  
  ```json
  {
    "schema_version": 1,
    "overall_status": "fail",
    "checks": {
      "runtime.provenance": {
        "id": "runtime.provenance",
        "category": "Environment",
        "status": "ok",
        "summary": "local debug build",
        "details": {
          "version": "0.0.0",
          "install method": "other",
          "commit": "unknown"
        }
      },
      "sandbox.helpers": {
        "id": "sandbox.helpers",
        "category": "Configuration",
        "status": "ok",
        "summary": "restricted fs + restricted network · approval OnRequest",
        "details": {
          "approval policy": "OnRequest",
          "filesystem sandbox": "restricted",
          "network sandbox": "restricted"
        }
      }
    }
  }
  ```
  
  ### `/feedback` new sentry attachment
  
  <img width="938" height="798" alt="CleanShot 2026-05-13 at 15 36 14"
  src="https://github.com/user-attachments/assets/715e62e0-d7b4-4fea-a35a-fd5d5d33c4c0"
  />
  
  ### New section in CLI issue template
  
  <img width="1164" height="435" alt="CleanShot 2026-05-13 at 15 47 24"
  src="https://github.com/user-attachments/assets/9081dc25-a28c-4afa-8ba1-e299c2b4031d"
  />
  
  ## How to Test
  
  1. Run `cargo run --bin codex -- doctor --no-color`.
  2. Confirm the detailed report is the default and includes promoted
  Notes, grouped sections, terminal details, state DB integrity, rollout
  stats, provider reachability, WebSocket diagnostics, and app-server
  status.
  3. Run `cargo run --bin codex -- doctor --summary --no-color`.
  4. Confirm the compact view keeps the same sections and summary counts
  but omits detailed key/value rows.
  5. Run `cargo run --bin codex -- doctor --json`.
  6. Confirm the output is redacted JSON, `checks` is an object keyed by
  check id, and each check's `details` is a key/value object.
  7. Preview the CLI bug issue template and confirm the `Codex doctor
  report` field appears after the terminal field, asks for `codex doctor
  --json`, and renders pasted output as JSON.
  8. Start a feedback flow that includes logs.
  9. Confirm the upload consent copy lists `codex-doctor-report.json`
  alongside the log attachments.
  
  Targeted tests:
  
  - `cargo test -p codex-cli doctor`
  - `cargo test -p codex-app-server
  doctor_report_tags_summarize_status_counts`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-tui feedback_view`
  - `just argument-comment-lint`
  - `git diff --check`

  Felipe Coury · 2026-05-13 21:23:19 +00:00
  9798eb377a