Commit Graph
12654 Commits
Author SHA1 Message Date
Michael Bolin f35273a3c3 merge commit for archive created by Sapling 2026-04-22 21:04:03 -07:00
Michael Bolin 9047f9a16c tests: isolate approval fixtures from host rules 2026-04-22 21:02:31 -07:00
Michael Bolin 6be0482c00 shell-escalation: carry resolved permission profiles 2026-04-22 21:02:31 -07:00
Michael Bolin b00800a536 mcp: include permission profiles in sandbox state 2026-04-22 21:02:31 -07:00
Michael Bolin e4bc8d21b2 tui: carry permission profiles on user turns 2026-04-22 21:02:31 -07:00
Michael Bolin 9fdabab8ae tui: sync session permission profiles 2026-04-22 21:02:31 -07:00
Michael Bolin f8036779b9 app-server: accept command permission profiles 2026-04-22 21:02:31 -07:00
Michael Bolin 4a43379515 protocol: report session permission profiles 2026-04-22 21:02:31 -07:00
Michael Bolin 9955eacd22 tui: fix approvals popup disabled shortcut test (#19072)
## Why

This regressed in #19063, which made `GuardianApproval` stable and
enabled by default. That adds an enabled `Auto-review` row to the
permissions popup, but `approvals_popup_navigation_skips_disabled` still
assumed the disabled `Full Access` row lived behind a hard-coded numeric
shortcut, so the test started selecting a different row and closing the
popup instead of verifying disabled-row behavior.

## What

- disable `GuardianApproval` in
`approvals_popup_navigation_skips_disabled` so the popup layout matches
the scenario the test is exercising
- choose the hidden numeric shortcut for the disabled `Full Access` row
by platform (`2` on non-Windows, `3` on Windows where `Read Only` is
shown) before asserting that selecting the disabled row leaves the popup
open

## Testing

- `cargo test -p codex-tui --lib
chatwidget::tests::permissions::approvals_popup_navigation_skips_disabled
-- --exact --nocapture`
- `cargo test -p codex-tui --lib chatwidget::tests::permissions --
--nocapture`
- `cargo test -p codex-tui`
2026-04-22 21:01:26 -07:00
Michael Bolin 8b78b46adb Merge b8b7ff5d9f into sapling-pr-archive-bolinfest 2026-04-22 20:21:01 -07:00
Michael Bolin b8b7ff5d9f protocol: report session permission profiles 2026-04-22 20:20:45 -07:00
Michael Bolin e8ba912fcc test: set Rust test thread stack size (#19067)
## Summary

Set `RUST_MIN_STACK=8388608` for Rust test entry points so
libtest-spawned test threads get an 8 MiB stack.

The Windows BuildBuddy failure on #18893 showed
`//codex-rs/tui:tui-unit-tests` exiting with a stack overflow in a
`#[tokio::test]` even though later test binaries in the shard printed
successful summaries. Default `#[tokio::test]` uses a current-thread
Tokio runtime, which means the async test body is driven on libtest's
std-spawned test thread. Increasing the test thread stack addresses that
failure mode directly.

To date, we have been fixing these stack-pressure problems with
localized future-size reductions, such as #13429, and by adding
`Box::pin()` in specific async wrapper chains. This gives us a baseline
test-runner stack size instead of continuing to patch individual tests
only after CI finds another large async future.

## What changed

- Added `common --test_env=RUST_MIN_STACK=8388608` in `.bazelrc` so
Bazel test actions receive the env var through Bazel's cache-keyed test
environment path.
- Set the same `RUST_MIN_STACK` value for Cargo/nextest CI entry points
and `just test`.
- Annotated the existing Windows Bazel linker stack reserve as 8 MiB so
it stays aligned with the libtest thread stack size.

## Testing

- `just --list`
- parsed `.github/workflows/rust-ci.yml` and
`.github/workflows/rust-ci-full.yml` with Ruby's YAML loader
- compared `bazel aquery` `TestRunner` action keys before/after explicit
`--test_env=RUST_MIN_STACK=...` and after moving the Bazel env to
`.bazelrc`
- `bazel test //codex-rs/tui:tui-unit-tests --test_output=errors`
- failed locally on the existing sandbox-specific status snapshot
permission mismatch, but loaded the Starlark changes and ran the TUI
test shards
2026-04-22 19:51:49 -07:00
Michael Bolin d698279f4c merge commit for archive created by Sapling 2026-04-22 19:32:44 -07:00
Michael Bolin 0c112c279e increase stack size 2026-04-22 19:32:09 -07:00
Michael Bolin 214c27d86e Merge 536bb065f4 into sapling-pr-archive-bolinfest 2026-04-22 19:30:30 -07:00
Michael Bolin 536bb065f4 increase stack size 2026-04-22 19:30:23 -07:00
Michael Bolin 60d6ba6782 Merge c52b5b5ce2 into sapling-pr-archive-bolinfest 2026-04-22 19:21:07 -07:00
Michael Bolin c52b5b5ce2 increase stack size 2026-04-22 19:20:06 -07:00
Dylan Hurd 5e71da1424 feat(request-permissions) approve with strict review (#19050)
## Summary
Allow the user to approve a request_permissions_tool request with the
condition that all commands in the rest of the turn are reviewed by
guardian, regardless of sandbox status.

## Testing
- [x] Added unit tests
- [x] Ran locally
2026-04-23 01:56:32 +00:00
Dylan Hurd c6ab601824 chore(auto-review) feature => stable (#19063)
## Summary
Turn on Auto Review

## Testing
- [x] Update unit tests
2026-04-22 18:51:39 -07:00
Matthew Zeng 8f0a92c1e5 Fix relative stdio MCP cwd fallback (#19031) 2026-04-22 17:52:17 -07:00
Michael Bolin 3cc3763e6c core: box multi-agent wrapper futures (#19059)
## Why

While debugging the Windows stack overflows we saw in
[#13429](https://github.com/openai/codex/pull/13429) and then again in
[#18893](https://github.com/openai/codex/pull/18893), I hit another
overflow in
`tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.

That test drives the legacy multi-agent spawn / close / resume path. The
behavior was fine, but several thin async wrappers were still inlining
much larger `AgentControl` futures into their callers, which was enough
to overflow the default Windows stack.

## What

- Box the thin `AgentControl` wrappers around `spawn_agent_internal`,
`resume_single_agent_from_rollout`, and `shutdown_agent_tree`.
- Box the corresponding legacy `multi_agents` handler calls in `spawn`,
`resume_agent`, and `close_agent`.
- Keep behavior unchanged while reducing future size on this call path
so the Windows test no longer overflows its stack.

## Testing

- `cargo test -p codex-core --lib
tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed
-- --exact --nocapture`
- `cargo test -p codex-core` (this still hit unrelated local
integration-test failures because `codex.exe` / `test_stdio_server.exe`
were not present in this shell; the relevant unit tests passed)
2026-04-22 17:48:13 -07:00
Ahmed IbrahimandCodex 0e78ce80ee [3/4] Add executor-backed RMCP HTTP client (#18583)
### Why
The RMCP layer needs a Streamable HTTP client that can talk either
directly over `reqwest` or through the executor HTTP runner without
duplicating MCP session logic higher in the stack. This PR adds that
client-side transport boundary so remote Streamable HTTP MCP can reuse
the same RMCP flow as the local path.

### What
- Add a shared `rmcp-client/src/streamable_http/` module with:
  - `transport_client.rs` for the local-or-remote transport enum
  - `local_client.rs` for the direct `reqwest` implementation
  - `remote_client.rs` for the executor-backed implementation
  - `common.rs` for the small shared Streamable HTTP helpers
- Teach `RmcpClient` to build Streamable HTTP transports in either local
or remote mode while keeping the existing OAuth ownership in RMCP.
- Translate remote POST, GET, and DELETE session operations into
executor `http/request` calls.
- Preserve RMCP session expiry handling and reconnect behavior for the
remote transport.
- Add remote transport coverage in
`rmcp-client/tests/streamable_http_remote.rs` and keep the shared test
support in `rmcp-client/tests/streamable_http_test_support.rs`.

### Verification
- `cargo check -p codex-rmcp-client`
- online CI

### Stack
1. #18581 protocol
2. #18582 runner
3. #18583 RMCP client
4. #18584 manager wiring and local/remote coverage

---------

Co-authored-by: Codex <noreply@openai.com>
2026-04-22 17:38:04 -07:00
Michael Bolin 9425d057e5 merge commit for archive created by Sapling 2026-04-22 17:28:53 -07:00
Michael Bolin 754b882112 app-server: accept command permission profiles 2026-04-22 17:28:38 -07:00
Won Park 83ec1eb5d6 Rename approvals reviewer variant to auto-review (#19056)
## Why

`approvals_reviewer` now uses `auto_review` as the canonical config/API
value after #18504, but the Rust enum variant and nearby helper/test
names still used `GuardianSubagent` / guardian approval wording. That
made follow-up code and reviews confusing even though the external value
had already moved to Auto-review.

## What changed

- Renamed `ApprovalsReviewer::GuardianSubagent` to
`ApprovalsReviewer::AutoReview`.
- Updated protocol, app-server, config, core, TUI, exec, and analytics
test callsites.
- Renamed nearby helper/test names from guardian approval wording to
Auto-review wording where they refer to the approvals reviewer mode.
- Preserved wire compatibility:
  - `auto_review` remains the canonical serialized value.
  - `guardian_subagent` remains accepted as a legacy alias.

This intentionally does not rename the `[features].guardian_approval`
key, `Feature::GuardianApproval`, `core/src/guardian`, analytics event
names, or app-server Guardian review event types.

## Verification

- `cargo test -p codex-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
- `cargo test -p codex-app-server-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
- `cargo test -p codex-config approvals_reviewer`
- `cargo test -p codex-tui update_feature_flags`
- `cargo test -p codex-core permissions_instructions`
- `cargo test -p codex-tui permissions_selection`
2026-04-22 17:22:35 -07:00
Andrei Eternal eed0e07825 hooks: emit Bash PostToolUse when exec_command completes via write_stdin (#18888)
Fixes #16246.

## Why

`exec_command` already emits `PreToolUse`, but long-running unified exec
commands that finish on a later `write_stdin` poll could miss the
matching `PostToolUse`. That left the Bash hook lifecycle inconsistent,
broke expectations around `tool_use_id` and `tool_input.command`, and
meant `PostToolUse` block/replacement feedback could fail to replace the
final session output before it reached model context.

This keeps the fix scoped to the `exec_command` / `write_stdin`
lifecycle. Broader non-Bash hook expansion is still out of scope here
and remains tracked separately in #16732.

## What changed

- Compute and store `PostToolUsePayload` while handlers still have
access to their concrete output type, and carry `tool_use_id` through
that payload.
- Preserve the original hook-facing `exec_command` string through
unified exec state (`ExecCommandRequest`, `ProcessEntry`,
`PreparedProcessHandles`, and `ExecCommandToolOutput`) via
`hook_command`, and remove the now-unused `session_command` output
metadata.
- Emit exactly one Bash `PostToolUse` for long-running `exec_command`
sessions when a later `write_stdin` poll observes final completion,
using the original `exec_command` call id and hook-facing command.
- Keep one-shot `exec_command` behavior aligned with the same payload
construction, including interactive completions that return a final
result directly.
- Apply `PostToolUse` block/replacement feedback before the final
`write_stdin` completion output is sent back to the model.
- Keep `write_stdin` itself out of `PreToolUse` matching so it continues
to act as transport/polling for the original Bash tool call.
- Restore plain matcher behavior for tool-name matchers such as `Bash`
and `Edit|Write`, while still treating patterns with regex characters
(for example `mcp__.*`) as regexes.
- Add unit coverage for unified exec payload construction and parallel
session separation, plus a core integration regression that verifies a
blocked `PostToolUse` replaces the final `write_stdin` output in model
context.

## Testing

- `cargo test -p codex-hooks`
- `cargo test -p codex-core post_tool_use_payload`
- `cargo test -p codex-core
post_tool_use_blocks_when_exec_session_completes_via_write_stdin`
2026-04-22 17:14:22 -07:00
Michael Bolin 7beae72cd7 merge commit for archive created by Sapling 2026-04-22 17:10:06 -07:00
Michael Bolin 3d53e2c04f app-server: accept command permission profiles 2026-04-22 17:09:35 -07:00
Michael Bolin 3479520524 Merge 7868e1a036 into sapling-pr-archive-bolinfest 2026-04-22 17:01:09 -07:00
Michael Bolin ccd0da0152 protocol: report session permission profiles 2026-04-22 17:00:49 -07:00
Michael Bolin 7868e1a036 tests: isolate approval fixtures from host rules 2026-04-22 17:00:49 -07:00
Michael Bolin dfd66aa244 shell-escalation: carry resolved permission profiles 2026-04-22 17:00:49 -07:00
Michael Bolin 9a5c6fd46d mcp: include permission profiles in sandbox state 2026-04-22 17:00:49 -07:00
Michael Bolin 727ef387d4 tui: carry permission profiles on user turns 2026-04-22 17:00:49 -07:00
Michael Bolin 89090ff058 tui: sync session permission profiles 2026-04-22 17:00:49 -07:00
Michael Bolin 9ba2bcced6 app-server: accept command permission profiles 2026-04-22 17:00:49 -07:00
Michael Bolin 6ca038bbd1 rollout: persist turn permission profiles (#18281)
## Why

Resume and reconstruction need to preserve the permissions that were
active for each user turn. If rollouts only keep legacy sandbox fields,
replay cannot faithfully represent profile-shaped overrides introduced
earlier in the stack.

## What changed

This records `permission_profile` on user-turn rollout events,
reconstructs it through history/state extraction, and updates rollout
reconstruction and related fixtures to keep the field explicit.

## Verification

- `cargo test -p codex-core --test all permissions_messages --
--nocapture`
- `cargo test -p codex-core --test all request_permissions --
--nocapture`











































---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18281).
* #18288
* #18287
* #18286
* #18285
* #18284
* #18283
* #18282
* __->__ #18281
2026-04-22 17:00:29 -07:00
Michael Bolin aef50ebe16 merge commit for archive created by Sapling 2026-04-22 16:41:20 -07:00
Michael Bolin a3acf5d517 tests: isolate approval fixtures from host rules 2026-04-22 16:37:12 -07:00
Michael Bolin 7f899ebaa0 shell-escalation: carry resolved permission profiles 2026-04-22 16:37:12 -07:00
Michael Bolin 864c0ca198 mcp: include permission profiles in sandbox state 2026-04-22 16:37:12 -07:00
Michael Bolin e24bd31a63 tui: carry permission profiles on user turns 2026-04-22 16:37:12 -07:00
Michael Bolin a5332b3967 tui: sync session permission profiles 2026-04-22 16:37:12 -07:00
Michael Bolin 75dc7b710a app-server: accept command permission profiles 2026-04-22 16:37:12 -07:00
Michael Bolin 40efdc08d6 protocol: report session permission profiles 2026-04-22 16:37:12 -07:00
Michael Bolin c701334a5f Merge e520e3e256 into sapling-pr-archive-bolinfest 2026-04-22 16:34:56 -07:00
Michael Bolin 76e4a7f099 rollout: persist turn permission profiles 2026-04-22 16:34:38 -07:00
Michael Bolin e520e3e256 tests: isolate approval fixtures from host rules 2026-04-22 16:34:38 -07:00
Michael Bolin 3a19a19ba5 shell-escalation: carry resolved permission profiles 2026-04-22 16:34:38 -07:00