mirror of
https://github.com/openai/codex.git
synced 2026-05-15 08:42:34 +00:00
ee/pause-queue-sends-core
27 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Felipe Coury
|
9798eb377a |
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` |
||
|
Charlie Marsh
|
54ef99a365 |
Disable empty Cargo test targets (#21584)
## Summary `cargo test` has entails both running standard Rust tests and doctests. It turns out that the doctest discovery is fairly slow, and it's a cost you pay even for crates that don't include any doctests. This PR disables doctests with `doctest = false` for crates that lack any doctests. For the collection of crates below, this speeds up test execution by >4x. E.g., before this PR: ``` Benchmark 1: cargo test -p codex-utils-absolute-path -p codex-utils-cache -p codex-utils-cli -p codex-utils-home-dir -p codex-utils-output-truncation -p codex-utils-path -p codex-utils-string -p codex-utils-template -p codex-utils-elapsed -p codex-utils-json-to-toml Time (mean ± σ): 1.849 s ± 4.455 s [User: 0.752 s, System: 1.367 s] Range (min … max): 0.418 s … 14.529 s 10 runs ``` And after: ``` Benchmark 1: cargo test -p codex-utils-absolute-path -p codex-utils-cache -p codex-utils-cli -p codex-utils-home-dir -p codex-utils-output-truncation -p codex-utils-path -p codex-utils-string -p codex-utils-template -p codex-utils-elapsed -p codex-utils-json-to-toml Time (mean ± σ): 428.6 ms ± 6.9 ms [User: 187.7 ms, System: 219.7 ms] Range (min … max): 418.0 ms … 436.8 ms 10 runs ``` For a single crate, with >2x speedup, before: ``` Benchmark 1: cargo test -p codex-utils-string Time (mean ± σ): 491.1 ms ± 9.0 ms [User: 229.8 ms, System: 234.9 ms] Range (min … max): 480.9 ms … 512.0 ms 10 runs ``` And after: ``` Benchmark 1: cargo test -p codex-utils-string Time (mean ± σ): 213.9 ms ± 4.3 ms [User: 112.8 ms, System: 84.0 ms] Range (min … max): 206.8 ms … 221.0 ms 13 runs ``` Co-authored-by: Codex <noreply@openai.com> |
||
|
pakrym-oai
|
acac786d91 |
[codex] add account id to feedback uploads (#21498)
## Why Feedback uploads already carry auth-derived context like `chatgpt_user_id`, but they do not include the authenticated workspace/account id. Adding `account_id` makes feedback triage easier when a user can operate across multiple ChatGPT workspaces. ## What changed - emit auth-derived `account_id` into feedback tags in `app-server` before the feedback snapshot is uploaded - preserve that tag through `codex-feedback` upload tag assembly alongside the existing merge behavior for other tags - extend `codex-feedback` coverage to assert that snapshot-derived `account_id` is present in uploaded tags ## Verification - `cargo test -p codex-feedback upload_tags_include_client_tags_and_preserve_reserved_fields` - `cargo test -p codex-app-server --lib feedback_processor` |
||
|
Won Park
|
5cf0adba93 |
Include auto-review rollout in feedback uploads (#20064)
## Summary - include the live auto-review trunk rollout when `/feedback` uploads logs - upload that attachment as `auto-review-rollout-<parent-thread-id>.jsonl` so it is distinguishable from the parent rollout - show the same auto-review attachment name in the TUI consent popup ## Scope - this only covers the live cached auto-review trunk for the current parent thread - it does not add durable historical parent->auto-review lookup - it does not add persisted rollout support for ephemeral parallel review forks ## UI <img width="599" height="185" alt="Screenshot 2026-04-28 at 1 17 18 PM" src="https://github.com/user-attachments/assets/6a0e79c2-5d21-4702-8a89-f765778bc9e9" /> ## Validation - `cargo test -p codex-core cached_guardian_subagent_exposes_its_rollout_path` - `cargo test -p codex-feedback` - `cargo test -p codex-app-server` - `cargo test -p codex-tui feedback_upload_consent_popup_snapshot` - `cargo test -p codex-tui feedback_good_result_consent_popup_includes_connectivity_diagnostics_filename` ## Known unrelated local failures - `cargo test -p codex-core` currently fails in the pre-existing proxy env snapshot test `tools::runtimes::tests::maybe_wrap_shell_lc_with_snapshot_keeps_user_proxy_env_when_proxy_inactive` - `cargo test -p codex-tui` currently hits pre-existing `status::*` snapshot drift unrelated to this change ## Follow-Up - persist parallel auto-review fork sessions so /feedback can include their rollout history too - attach each persisted fork as its own clearly named file, for example auto-review-rollout-<parent-thread-id>-fork <n>.jsonl, instead of merging multiple Guardian sessions into one attachment - keep the same live-session-only scope initially; durable historical parent -> auto-review lookup can remain a separate decision if we later need feedback from resumed sessions |
||
|
ningyi-oai
|
be13f03c39 |
Pass turn id with feedback uploads (#17314)
## Summary - Add an optional `tags` dictionary to feedback upload params. - Capture the active app-server turn id in the TUI and submit it as `tags.turn_id` with `/feedback` uploads. - Merge client-provided feedback tags into Sentry feedback tags while preserving reserved system fields like `thread_id`, `classification`, `cli_version`, `session_source`, and `reason`. ## Behavior / impact Existing feedback upload callers remain compatible because `tags` is optional and nullable. The wire shape is still a normal JSON object / TypeScript dictionary, so adding future feedback metadata will not require a new top-level protocol field each time. This change only adds feedback metadata for Codex CLI/TUI uploads; it does not affect existing pipelines, DAGs, exports, or downstream consumers unless they choose to read the new `turn_id` feedback tag. ## Tests - `cargo fmt -- --config imports_granularity=Item` passed; stable rustfmt warned that `imports_granularity` is nightly-only. - `cargo run -p codex-app-server-protocol --bin write_schema_fixtures` - `cargo test -p codex-feedback upload_tags_include_client_tags_and_preserve_reserved_fields` - `cargo test -p codex-app-server-protocol schema_fixtures_match_generated` - `cargo test -p codex-tui build_feedback_upload_params` - `cargo test -p codex-tui live_app_server_turn_started_sets_feedback_turn_id` - `cargo check -p codex-app-server --tests` - `git diff --check` --------- Co-authored-by: Codex <noreply@openai.com> |
||
|
pakrym-oai
|
413c1e1fdf |
[codex] reduce module visibility (#16978)
## Summary - reduce public module visibility across Rust crates, preferring private or crate-private modules with explicit crate-root public exports - update external call sites and tests to use the intended public crate APIs instead of reaching through module trees - add the module visibility guideline to AGENTS.md ## Validation - `cargo check --workspace --all-targets --message-format=short` passed before the final fix/format pass - `just fix` completed successfully - `just fmt` completed successfully - `git diff --check` passed |
||
|
Eric Traut
|
4b8bab6ad3 |
Remove OPENAI_BASE_URL config fallback (#16720)
The `OPENAI_BASE_URL` environment variable has been a significant support issue, so we decided to deprecate it in favor of an `openai_base_url` config key. We've had the deprecation warning in place for about a month, so users have had time to migrate to the new mechanism. This PR removes support for `OPENAI_BASE_URL` entirely. |
||
|
Ahmed Ibrahim
|
6fff9955f1 |
extract models manager and related ownership from core (#16508)
## Summary - split `models-manager` out of `core` and add `ModelsManagerConfig` plus `Config::to_models_manager_config()` so model metadata paths stop depending on `core::Config` - move login-owned/auth-owned code out of `core` into `codex-login`, move model provider config into `codex-model-provider-info`, move API bridge mapping into `codex-api`, move protocol-owned types/impls into `codex-protocol`, and move response debug helpers into a dedicated `response-debug-context` crate - move feedback tag emission into `codex-feedback`, relocate tests to the crates that now own the code, and keep broad temporary re-exports so this PR avoids a giant import-only rewrite ## Major moves and decisions - created `codex-models-manager` as the owner for model cache/catalog/config/model info logic, including the new `ModelsManagerConfig` struct - created `codex-model-provider-info` as the owner for provider config parsing/defaults and kept temporary `codex-login`/`codex-core` re-exports for old import paths - moved `api_bridge` error mapping + `CoreAuthProvider` into `codex-api`, while `codex-login::api_bridge` temporarily re-exports those symbols and keeps the `auth_provider_from_auth` wrapper - moved `auth_env_telemetry` and `provider_auth` ownership to `codex-login` - moved `CodexErr` ownership to `codex-protocol::error`, plus `StreamOutput`, `bytes_to_string_smart`, and network policy helpers to protocol-owned modules - created `codex-response-debug-context` for `extract_response_debug_context`, `telemetry_transport_error_message`, and related response-debug plumbing instead of leaving that behavior in `core` - moved `FeedbackRequestTags`, `emit_feedback_request_tags`, and `emit_feedback_request_tags_with_auth_env` to `codex-feedback` - deferred removal of temporary re-exports and the mechanical import rewrites to a stacked follow-up PR so this PR stays reviewable ## Test moves - moved auth refresh coverage from `core/tests/suite/auth_refresh.rs` to `login/tests/suite/auth_refresh.rs` - moved text encoding coverage from `core/tests/suite/text_encoding_fix.rs` to `protocol/src/exec_output_tests.rs` - moved model info override coverage from `core/tests/suite/model_info_overrides.rs` to `models-manager/src/model_info_overrides_tests.rs` --------- Co-authored-by: Codex <noreply@openai.com> |
||
|
Michael Bolin
|
9a8730f31e |
ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)
## Why Bazel clippy now catches lints that `cargo clippy` can still miss when a crate under `codex-rs` forgets to opt into workspace lints. The concrete example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel flagged a clippy violation in `models_cache.rs`, but Cargo did not because that crate inherited workspace package metadata without declaring `[lints] workspace = true`. We already mirror the workspace clippy deny list into Bazel after [#15955](https://github.com/openai/codex/pull/15955), so we also need a repo-side check that keeps every `codex-rs` manifest opted into the same workspace settings. ## What changed - add `.github/scripts/verify_cargo_workspace_manifests.py`, which parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies: - `version.workspace = true` - `edition.workspace = true` - `license.workspace = true` - `[lints] workspace = true` - top-level crate names follow the `codex-*` / `codex-utils-*` conventions, with explicit exceptions for `windows-sandbox-rs` and `utils/path-utils` - run that script in `.github/workflows/ci.yml` - update the current outlier manifests so the check is enforceable immediately - fix the newly exposed clippy violations in the affected crates (`app-server/tests/common`, `file-search`, `feedback`, `shell-escalation`, and `debug-client`) --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353). * #16351 * __->__ #16353 |
||
|
Michael Bolin
|
61dfe0b86c |
chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)
## Why `argument-comment-lint` was green in CI even though the repo still had many uncommented literal arguments. The main gap was target coverage: the repo wrapper did not force Cargo to inspect test-only call sites, so examples like the `latest_session_lookup_params(true, ...)` tests in `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path. This change cleans up the existing backlog, makes the default repo lint path cover all Cargo targets, and starts rolling that stricter CI enforcement out on the platform where it is currently validated. ## What changed - mechanically fixed existing `argument-comment-lint` violations across the `codex-rs` workspace, including tests, examples, and benches - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to `--all-targets` unless the caller explicitly narrows the target set - fixed both wrappers so forwarded cargo arguments after `--` are preserved with a single separator - documented the new default behavior in `tools/argument-comment-lint/README.md` - updated `rust-ci` so the macOS lint lane keeps the plain wrapper invocation and therefore enforces `--all-targets`, while Linux and Windows temporarily pass `-- --lib --bins` That temporary CI split keeps the stricter all-targets check where it is already cleaned up, while leaving room to finish the remaining Linux- and Windows-specific target-gated cleanup before enabling `--all-targets` on those runners. The Linux and Windows failures on the intermediate revision were caused by the wrapper forwarding bug, not by additional lint findings in those lanes. ## Validation - `bash -n tools/argument-comment-lint/run.sh` - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh` - shell-level wrapper forwarding check for `-- --lib --bins` - shell-level wrapper forwarding check for `-- --tests` - `just argument-comment-lint` - `cargo test` in `tools/argument-comment-lint` - `cargo test -p codex-terminal-detection` ## Follow-up - Clean up remaining Linux-only target-gated callsites, then switch the Linux lint lane back to the plain wrapper invocation. - Clean up remaining Windows-only target-gated callsites, then switch the Windows lint lane back to the plain wrapper invocation. |
||
|
Eric Traut
|
b5f475ed16 |
Add timestamps to feedback log lines (#13688)
`/feedback` uploads can include `codex-logs.log` from the in-memory
feedback logger path. That logger was emitting level + message without a
timestamp, which made some uploaded logs much harder to inspect. This
change makes the feedback logger use an explicit timer so
feedback-captured log lines include timestamps consistently.
This is not Windows-specific code. The bug showed up in Windows reports
because those uploads were hitting the feedback-buffer path more often,
while Linux/macOS reports were typically coming from the SQLite feedback
export, which already prefixes timestamps.
Here's an example of a log that is missing the timestamps:
```
TRACE app-server request: getAuthStatus
TRACE app-server request: model/list
INFO models cache: evaluating cache eligibility
INFO models cache: attempting load_fresh
INFO models cache: loaded cache file
INFO models cache: cache version mismatch
INFO models cache: no usable cache entry
DEBUG
INFO models cache: cache miss, fetching remote models
TRACE windows::current_platform is called
TRACE Returning Info { os_type: Windows, version: Semantic(10, 0, 26200), edition: Some("Windows 11 Professional"), codename: None, bitness: X64, architecture: Some("x86_64") }
```
|
||
|
rhan-oai
|
9fcbbeb5ae |
[diagnostics] show diagnostics earlier in workflow (#13604)
<img width="591" height="243" alt="Screenshot 2026-03-05 at 10 17 06 AM" src="https://github.com/user-attachments/assets/84a6658b-6017-4602-b1f8-2098b9b5eff9" /> - show feedback earlier - preserve raw literal env vars (no trimming, sanitizing, etc.) |
||
|
rhan-oai
|
e951ef4374 |
[feedback] diagnostics (#13292)
- added header logic to display diagnostics on cli - added logic for collecting env vars <img width="606" height="327" alt="Screenshot 2026-03-03 at 3 49 31 PM" src="https://github.com/user-attachments/assets/05e78c56-8cb3-47fa-abaf-3e57f1fdd8e2" /> <img width="690" height="353" alt="Screenshot 2026-03-02 at 6 47 54 PM" src="https://github.com/user-attachments/assets/e470b559-13f4-44d9-897f-bc398943c6d1" /> |
||
|
Charley Cunningham
|
c4bd0aa3b9 |
app-server: source /feedback logs from sqlite at trace level (#12969)
## Summary
- write app-server SQLite logs at TRACE level when SQLite is enabled
- source app-server `/feedback` log attachments from SQLite for the
requested thread when available
- flush buffered SQLite log writes before `/feedback` queries them so
newly emitted events are not lost behind the async inserter
- include same-process threadless SQLite rows in those `/feedback` logs
so the attachment matches the process-wide feedback buffer more closely
- keep the existing in-memory ring buffer fallback unchanged, including
when the SQLite query returns no rows
## Details
- add a byte-bounded `query_feedback_logs` helper in `codex-state` so
`/feedback` does not fetch all rows before truncating
- scope SQLite feedback logs to the requested thread plus threadless
rows from the same `process_uuid`
- format exported SQLite feedback lines with the log level prefix to
better match the in-memory feedback formatter
- add an explicit `LogDbLayer::flush()` control path and await it in
app-server before querying SQLite for feedback logs
- pass optional SQLite log bytes through `codex-feedback` as the
`codex-logs.log` attachment override
- leave TUI behavior unchanged apart from the updated `upload_feedback`
call signature
- add regression coverage for:
- newest-within-budget ordering
- excluding oversized newest rows
- including same-process threadless rows
- keeping the newest suffix across mixed thread and threadless rows
- matching the feedback formatter shape aside from span prefixes
- falling back to the in-memory snapshot when SQLite returns no logs
- flushing buffered SQLite rows before querying
## Follow-up
- SQLite feedback exports still do not reproduce span prefixes like
`feedback-thread{thread_id=...}:`; there is a `TODO(ccunningham)` in
`codex-rs/state/src/log_db.rs` for that follow-up.
## Testing
- `cd codex-rs && cargo test -p codex-state`
- `cd codex-rs && cargo test -p codex-app-server`
- `cd codex-rs && just fmt`
|
||
|
pakrym-oai
|
1bb7989b20 |
Add ability to attach extra files to feedback (#12370)
Allow clients to provide extra files. |
||
|
Fouad Matin
|
b37555dd75 |
add(feedback): over-refusal / safety check (#11948)
Add new feedback option for "Over-refusal / safety check" |
||
|
zbarsky-openai
|
2a06d64bc9 |
feat: add support for building with Bazel (#8875)
This PR configures Codex CLI so it can be built with [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc` includes configuration so that remote builds can be done using [BuildBuddy](https://www.buildbuddy.io). If you are familiar with Bazel, things should work as you expect, e.g., run `bazel test //... --keep-going` to run all the tests in the repo, but we have also added some new aliases in the `justfile` for convenience: - `just bazel-test` to run tests locally - `just bazel-remote-test` to run tests remotely (currently, the remote build is for x86_64 Linux regardless of your host platform). Note we are currently seeing the following test failures in the remote build, so we still need to figure out what is happening here: ``` failures: suite::compact::manual_compact_twice_preserves_latest_user_messages suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view ``` - `just build-for-release` to build release binaries for all platforms/architectures remotely To setup remote execution: - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI employees should also request org access at https://openai.buildbuddy.io/join/ with their `@openai.com` email address.) - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to `~/.bazelrc` (add the line `build --remote_header=x-buildbuddy-api-key=YOUR_KEY`) - Use `--config=remote` in your `bazel` invocations (or add `common --config=remote` to your `~/.bazelrc`, or use the `just` commands) ## CI In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners (we are working on supporting Windows, but that is not ready yet). Note that the failures we are seeing in `just bazel-remote-test` do not occur on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml` is green right now. The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so that macOS CI jobs build _remotely_ on Linux hosts (using the `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the root `BUILD.bazel`) using cross-compilation to build the macOS artifacts. Then these artifacts are downloaded locally to GitHub's macOS runner so the tests can be executed natively. This is the relevant config that enables this: ``` common:macos --config=remote common:macos --strategy=remote common:macos --strategy=TestRunner=darwin-sandbox,local ``` Because of the remote caching benefits we get from BuildBuddy, these new CI jobs can be extremely fast! For example, consider these two jobs that ran all the tests on Linux x86_64: - Bazel 1m37s https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875 - Cargo 9m20s https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875 For now, we will continue to run both the Bazel and Cargo jobs for PRs, but once we add support for Windows and running Clippy, we should be able to cutover to using Bazel exclusively for PRs, which should still speed things up considerably. We will probably continue to run the Cargo jobs post-merge for commits that land on `main` as a sanity check. Release builds will also continue to be done by Cargo for now. Earlier attempt at this PR: https://github.com/openai/codex/pull/8832 Earlier attempt to add support for Buck2, now abandoned: https://github.com/openai/codex/pull/8504 --------- Co-authored-by: David Zbarsky <dzbarsky@gmail.com> Co-authored-by: Michael Bolin <mbolin@openai.com> |
||
|
jif-oai
|
116059c3a0 |
chore: unify conversation with thread name (#8830)
Done and verified by Codex + refactor feature of RustRover |
||
|
pakrym-oai
|
1b5095b5d1 |
Attach more tags to feedback submissions (#8688)
Attach more tags to sentry feedback so it's easier to classify and debug without having to scan through logs. Formatting isn't amazing but it's a start. <img width="1234" height="276" alt="image" src="https://github.com/user-attachments/assets/521a349d-f627-4051-b511-9811cd5cd933" /> |
||
|
dependabot[bot]
|
3843cc7b34 |
chore(deps): bump sentry from 0.34.0 to 0.46.0 in /codex-rs (#8043)
Bumps [sentry](https://github.com/getsentry/sentry-rust) from 0.34.0 to 0.46.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/releases">sentry's releases</a>.</em></p> <blockquote> <h2>0.46.0</h2> <h3>Breaking changes</h3> <ul> <li>Removed the <code>ClientOptions</code> struct's <code>trim_backtraces</code> and <code>extra_border_frames</code> fields (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>). <ul> <li>These fields configured backtrace trimming, which is being removed in this release.</li> </ul> </li> </ul> <h3>Improvements</h3> <ul> <li>Removed backtrace trimming to align the Rust SDK with the general principle that Sentry SDKs should only truncate telemetry data when needed to comply with <a href="https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits">documented size limits</a> (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>). This change ensures that as much data as possible remains available for debugging. <ul> <li>If you notice any new issues being created for existing errors after this change, please open an issue on <a href="https://github.com/getsentry/sentry-rust/issues/new/choose">GitHub</a>.</li> </ul> </li> </ul> <h3>Fixes</h3> <ul> <li>fix: adjust sentry.origin for log integration (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/919">#919</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></li> </ul> <h2>0.45.0</h2> <h3>Breaking changes</h3> <ul> <li>Add custom variant to <code>AttachmentType</code> that holds an arbitrary String. (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/916">#916</a>)</li> </ul> <h2>0.44.0</h2> <h3>Breaking changes</h3> <ul> <li>feat(log): support combined LogFilters and RecordMappings (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/914">#914</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Breaking change: <code>sentry::integrations::log::LogFilter</code> has been changed to a <code>bitflags</code> struct.</li> <li>It's now possible to map a <code>log</code> record to multiple items in Sentry by combining multiple log filters in the filter, e.g. <code>log::Level::ERROR => LogFilter::Event | LogFilter::Log</code>.</li> <li>If using a custom <code>mapper</code> instead, it's possible to return a <code>Vec<sentry::integrations::log::RecordMapping></code> to map a <code>log</code> record to multiple items in Sentry.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>ref(log): send logs by default when logs feature flag is enabled (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/915">#915</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, the default Sentry <code>log</code> logger now sends logs for all events at or above INFO.</li> </ul> </li> <li>ref(logs): enable logs by default if logs feature flag is used (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/910">#910</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>This changes the default value of <code>sentry::ClientOptions::enable_logs</code> to <code>true</code>.</li> <li>This simplifies the setup of Sentry structured logs by requiring users to just add the <code>log</code> feature flag to the <code>sentry</code> dependency to opt-in to sending logs.</li> <li>When the <code>log</code> feature flag is enabled, the <code>tracing</code> and <code>log</code> integrations will send structured logs to Sentry for all logs/events at or above INFO level by default.</li> </ul> </li> </ul> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> <li>When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.</li> </ul> </li> <li>ref(tracing): use standard code attributes (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/899">#899</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Logs now carry the attributes <code>code.module.name</code>, <code>code.file.path</code> and <code>code.line.number</code> standardized in OTEL to surface the respective information, in contrast with the previously sent <code>tracing.module_path</code>, <code>tracing.file</code> and <code>tracing.line</code>.</li> </ul> </li> <li>fix(actix): capture only server errors (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/877">#877</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-rust/blob/master/CHANGELOG.md">sentry's changelog</a>.</em></p> <blockquote> <h2>0.46.0</h2> <h3>Breaking changes</h3> <ul> <li>Removed the <code>ClientOptions</code> struct's <code>trim_backtraces</code> and <code>extra_border_frames</code> fields (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>). <ul> <li>These fields configured backtrace trimming, which is being removed in this release.</li> </ul> </li> </ul> <h3>Improvements</h3> <ul> <li>Removed backtrace trimming to align the Rust SDK with the general principle that Sentry SDKs should only truncate telemetry data when needed to comply with <a href="https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits">documented size limits</a> (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/925">#925</a>). This change ensures that as much data as possible remains available for debugging. <ul> <li>If you notice any new issues being created for existing errors after this change, please open an issue on <a href="https://github.com/getsentry/sentry-rust/issues/new/choose">GitHub</a>.</li> </ul> </li> </ul> <h3>Fixes</h3> <ul> <li>fix: adjust sentry.origin for log integration (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/919">#919</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a></li> </ul> <h2>0.45.0</h2> <h3>Breaking changes</h3> <ul> <li>Add custom variant to <code>AttachmentType</code> that holds an arbitrary String. (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/916">#916</a>)</li> </ul> <h2>0.44.0</h2> <h3>Breaking changes</h3> <ul> <li>feat(log): support combined LogFilters and RecordMappings (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/914">#914</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>Breaking change: <code>sentry::integrations::log::LogFilter</code> has been changed to a <code>bitflags</code> struct.</li> <li>It's now possible to map a <code>log</code> record to multiple items in Sentry by combining multiple log filters in the filter, e.g. <code>log::Level::ERROR => LogFilter::Event | LogFilter::Log</code>.</li> <li>If using a custom <code>mapper</code> instead, it's possible to return a <code>Vec<sentry::integrations::log::RecordMapping></code> to map a <code>log</code> record to multiple items in Sentry.</li> </ul> </li> </ul> <h3>Behavioral changes</h3> <ul> <li>ref(log): send logs by default when logs feature flag is enabled (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/915">#915</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>If the <code>logs</code> feature flag is enabled, the default Sentry <code>log</code> logger now sends logs for all events at or above INFO.</li> </ul> </li> <li>ref(logs): enable logs by default if logs feature flag is used (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/910">#910</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>This changes the default value of <code>sentry::ClientOptions::enable_logs</code> to <code>true</code>.</li> <li>This simplifies the setup of Sentry structured logs by requiring users to just add the <code>log</code> feature flag to the <code>sentry</code> dependency to opt-in to sending logs.</li> <li>When the <code>log</code> feature flag is enabled, the <code>tracing</code> and <code>log</code> integrations will send structured logs to Sentry for all logs/events at or above INFO level by default.</li> </ul> </li> </ul> <h2>0.43.0</h2> <h3>Breaking changes</h3> <ul> <li>ref(tracing): rework tracing to Sentry span name/op conversion (<a href="https://redirect.github.com/getsentry/sentry-rust/pull/887">#887</a>) by <a href="https://github.com/lcian"><code>@lcian</code></a> <ul> <li>The <code>tracing</code> integration now uses the tracing span name as the Sentry span name by default.</li> <li>Before this change, the span name would be set based on the <code>tracing</code> span target (<code><module>::<function></code> when using the <code>tracing::instrument</code> macro).</li> <li>The <code>tracing</code> integration now uses <code><span target>::<span name></code> as the default Sentry span op (i.e. <code><module>::<function></code> when using <code>tracing::instrument</code>).</li> <li>Before this change, the span op would be set based on the <code>tracing</code> span name.</li> <li>Read below to learn how to customize the span name and op.</li> </ul> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Josh McKinney
|
ec49b56874 |
chore: add cargo-deny configuration (#7119)
- add GitHub workflow running cargo-deny on push/PR - document cargo-deny allowlist with workspace-dep notes and advisory ignores - align workspace crates to inherit version/edition/license for consistent checks |
||
|
Matthew Zeng
|
c31663d745 |
[feedback] Add source info into feedback metadata. (#7140)
Verified the source info is correctly attached based on whether it's cli or vscode. |
||
|
Ahmed Ibrahim
|
f178805252 | Add feedback upload request handling (#5682) | ||
|
Ahmed Ibrahim
|
88abbf58ce |
Followup feedback (#5663)
- Added files to be uploaded - Refactored - Updated title |
||
|
Ahmed Ibrahim
|
71f838389b |
Improve feedback (#5661)
<img width="1099" height="153" alt="image" src="https://github.com/user-attachments/assets/2c901884-8baf-4b1b-b2c4-bcb61ff42be8" /> <img width="1082" height="125" alt="image" src="https://github.com/user-attachments/assets/6336e6c9-9ace-46df-a383-a807ceffa524" /> <img width="1102" height="103" alt="image" src="https://github.com/user-attachments/assets/78883682-7e44-4fa3-9e04-57f7df4766fd" /> |
||
|
pakrym-oai
|
a4be4d78b9 |
Log more types of request IDs (#5645)
Different services return different sets of IDs, log all of them to simplify debugging. |
||
|
pakrym-oai
|
da5492694b | Add log upload support (#5257) |