Commit Graph

3704 Commits

  • feat(tui): prevent macOS idle sleep while turns run (#11711)
    ## Summary
    - add a shared `codex-core` sleep inhibitor that uses native macOS IOKit
    assertions (`IOPMAssertionCreateWithName` / `IOPMAssertionRelease`)
    instead of spawning `caffeinate`
    - wire sleep inhibition to turn lifecycle in `tui` (`TurnStarted`
    enables; `TurnComplete` and abort/error finalization disable)
    - gate this behavior behind a `/experimental` feature toggle
    (`[features].prevent_idle_sleep`) instead of a dedicated `[tui]` config
    flag
    - expose the toggle in `/experimental` on macOS; keep it under
    development on other platforms
    - keep behavior no-op on non-macOS targets
    
    <img width="1326" height="577" alt="image"
    src="https://github.com/user-attachments/assets/73fac06b-97ae-46a2-800a-30f9516cf8a3"
    />
    
    ## Testing
    - `cargo check -p codex-core -p codex-tui`
    - `cargo test -p codex-core sleep_inhibitor::tests -- --nocapture`
    - `cargo test -p codex-core
    tui_config_missing_notifications_field_defaults_to_enabled --
    --nocapture`
    - `cargo test -p codex-core prevent_idle_sleep_is_ -- --nocapture`
    
    ## Semantics and API references
    - This PR targets `caffeinate -i` semantics: prevent *idle system sleep*
    while allowing display idle sleep.
    - `caffeinate -i` mapping in Apple open source (`assertionMap`):
      - `kIdleAssertionFlag -> kIOPMAssertionTypePreventUserIdleSystemSleep`
    - Source:
    https://github.com/apple-oss-distributions/PowerManagement/blob/PowerManagement-1846.60.12/caffeinate/caffeinate.c#L52-L54
    - Apple IOKit docs for assertion types and API:
    -
    https://developer.apple.com/documentation/iokit/iopmlib_h/iopmassertiontypes
    -
    https://developer.apple.com/documentation/iokit/1557092-iopmassertioncreatewithname
      - https://developer.apple.com/library/archive/qa/qa1340/_index.html
    
    ## Codex Electron vs this PR (full stack path)
    - Codex Electron app requests sleep blocking with
    `powerSaveBlocker.start("prevent-app-suspension")`:
    -
    https://github.com/openai/codex/blob/main/codex/codex-vscode/electron/src/electron-message-handler.ts
    - Electron maps that string to Chromium wake lock type
    `kPreventAppSuspension`:
    -
    https://github.com/electron/electron/blob/main/shell/browser/api/electron_api_power_save_blocker.cc
    - Chromium macOS backend maps wake lock types to IOKit assertion
    constants and calls IOKit:
      - `kPreventAppSuspension -> kIOPMAssertionTypeNoIdleSleep`
    - `kPreventDisplaySleep / kPreventDisplaySleepAllowDimming ->
    kIOPMAssertionTypeNoDisplaySleep`
    -
    https://github.com/chromium/chromium/blob/main/services/device/wake_lock/power_save_blocker/power_save_blocker_mac.cc
    
    ## Why this PR uses a different macOS constant name
    - This PR uses `"PreventUserIdleSystemSleep"` directly, via
    `IOPMAssertionCreateWithName`, in
    `codex-rs/core/src/sleep_inhibitor.rs`.
    - Apple’s IOKit header documents `kIOPMAssertionTypeNoIdleSleep` as
    deprecated and recommends `kIOPMAssertPreventUserIdleSystemSleep` /
    `kIOPMAssertionTypePreventUserIdleSystemSleep`:
    -
    https://github.com/apple-oss-distributions/IOKitUser/blob/IOKitUser-100222.60.2/pwr_mgt.subproj/IOPMLib.h#L1000-L1030
    - So Chromium and this PR are using different constant names, but
    semantically equivalent idle-system-sleep prevention behavior.
    
    ## Future platform support
    The architecture is intentionally set up for multi-platform extensions:
    - UI code (`tui`) only calls `SleepInhibitor::set_turn_running(...)` on
    turn lifecycle boundaries.
    - Platform-specific behavior is isolated in
    `codex-rs/core/src/sleep_inhibitor.rs` behind `cfg(...)` blocks.
    - Feature exposure is centralized in `core/src/features.rs` and surfaced
    via `/experimental`.
    - Adding new OS backends should not require additional TUI wiring; only
    the backend internals and feature stage metadata need to change.
    
    Potential follow-up implementations:
    - Windows:
    - Add a backend using Win32 power APIs
    (`SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED)` as
    baseline).
    - Optionally move to `PowerCreateRequest` / `PowerSetRequest` /
    `PowerClearRequest` for richer assertion semantics.
    - Linux:
    - Add a backend using logind inhibitors over D-Bus
    (`org.freedesktop.login1.Manager.Inhibit` with `what="sleep"`).
      - Keep a no-op fallback where logind/D-Bus is unavailable.
    
    This PR keeps the cross-platform API surface minimal so future PRs can
    add Windows/Linux support incrementally with low churn.
    
    ---------
    
    Co-authored-by: jif-oai <jif@openai.com>
  • feat: switch on dying sub-agents (#11477)
    [codex-generated]
    
    ## Updated PR Description (Ready To Paste)
    
    ## Problem
    
    When a sub-agent thread emits `ShutdownComplete`, the TUI switches back
    to the primary thread.
    That was also happening for user-requested exits (for example `Ctrl+C`),
    which could prevent a
    clean app exit and unexpectedly resurrect the main thread.
    
    ## Mental model
    
    The app has one primary thread and one active thread. A non-primary
    active thread shutting down
    usually means "agent died, fail back to primary," but during
    `ExitMode::ShutdownFirst` shutdown
    means "the user is exiting," not "recover this session."
    
    ## Non-goals
    
    No change to thread lifecycle, thread-manager ownership, or shutdown
    protocol wire format.
    No behavioral changes to non-shutdown events.
    
    ## Tradeoffs
    
    This adds a small local marker (`pending_shutdown_exit_thread_id`)
    instead of inferring intent
    from event timing. It is deterministic and simple, but relies on
    correctly setting and clearing
    that marker around exit.
    
    ## Architecture
    
    `App` tracks which thread is intentionally being shut down for exit.
    `active_non_primary_shutdown_target` centralizes failover eligibility
    for `ShutdownComplete` and
    skips failover when shutdown matches the pending-exit thread.
    `handle_active_thread_event` handles non-primary failover before generic
    forwarding and clears the
    pending-exit marker only when the matching active thread completes
    shutdown.
    
    ## Observability
    
    User-facing info/error messages continue to indicate whether failover to
    the main thread succeeded.
    The shutdown-intent path is now explicitly documented inline for easier
    debugging.
    
    ## Tests
    
    Added targeted tests for `active_non_primary_shutdown_target` covering
    non-shutdown events,
    primary-thread shutdown, non-primary shutdown failover, pending exit on
    active thread (no failover),
    and pending exit for another thread (still failover).
    
    Validated with:
    - `cargo test -p codex-tui` (pass)
    
    ---------
    
    Co-authored-by: Josh McKinney <joshka@openai.com>
  • sandbox NUX metrics update (#11667)
    just updating metrics to match the NUX tweaks we made this week.
  • fix: reduce flakiness of compact_resume_after_second_compaction_preserves_history (#11663)
    ## Why
    `compact_resume_after_second_compaction_preserves_history` has been
    intermittently flaky in Windows CI.
    
    The test had two one-shot request matchers in the second compact/resume
    phase that could overlap, and it waited for the first `Warning` event
    after compaction. In practice, that made the test sensitive to
    platform/config-specific prompt shape and unrelated warning timing.
    
    ## What Changed
    - Hardened the second compaction matcher in
    `codex-rs/core/tests/suite/compact_resume_fork.rs` so it accepts
    expected compact-request variants while explicitly excluding the
    `AFTER_SECOND_RESUME` payload.
    - Updated `compact_conversation()` to wait for the specific compaction
    warning (`COMPACT_WARNING_MESSAGE`) rather than any `Warning` event.
    - Added an inline comment explaining why the matcher is intentionally
    broad but disjoint from the follow-up resume matcher.
    
    ## Test Plan
    - `cargo test -p codex-core --test all
    suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
    -- --exact`
    - Repeated the same test in a loop (40 runs) to check for local
    nondeterminism.
  • app-server-test-client websocket client and thread tools (#11755)
    - add websocket endpoint mode with default ws://127.0.0.1:4222 while
    keeping stdio codex-bin path compatibility
    - add thread-resume (follow stream) and thread-list commands for manual
    thread lifecycle testing
    - quickstart docs
  • core: limit search_tool_bm25 to Apps and clarify discovery guidance (#11669)
    ## Summary
    - Limit `search_tool_bm25` indexing to `codex_apps` tools only, so
    non-Apps MCP servers are no longer discoverable through this search
    path.
    - Move search-tool discovery guidance into the `search_tool_bm25` tool
    description (via template include) instead of injecting it as a separate
    developer message.
    - Update Apps discovery guidance wording to clarify when to use
    `search_tool_bm25` for Apps-backed systems (for example Slack, Google
    Drive, Jira, Notion) and when to call tools directly.
    - Remove dead `core` helper code (`filter_codex_apps_mcp_tools` and
    `codex_apps_connector_id`) that is no longer used after the
    tool-selection refactor.
    - Update `core` search-tool tests to assert codex-apps-only behavior and
    to validate guidance from the tool description.
    
    ## Validation
    -  `just fmt`
    -  `cargo test -p codex-core search_tool`
    - ⚠️ `cargo test -p codex-core` was attempted, but the run repeatedly
    stalled on
    `tools::js_repl::tests::js_repl_can_attach_image_via_view_image_tool`.
    
    ## Tickets
    - None
  • Fix memories output schema requirements (#11748)
    Summary
    - make the phase1 memories schema require `rollout_slug` while still
    allowing it to be `null`
    - update the corresponding test to check the required fields and
    nullable type list
    
    Testing
    - Not run (not requested)
  • feat: increase windows workers stack (#11736)
    Switched arg0 runtime initialization from tokio::runtime::Runtime::new()
    to an explicit multi-thread builder that sets the thread stack size to
    16MiB.
    
    This is only for Windows for now but we might need to do this for others
    in the future. This is required because Codex becomes quite large and
    Windows tends to consume stack a little bit faster (this is a known
    thing even though everyone seems to have different theory on it)
  • feat: add token usage on memories (#11618)
    Add aggregated token usage metrics on phase 1 of memories
  • fix(shell-tool-mcp) build dependencies (#11709)
    ## Summary
    Based on our most recent [release
    attempt](https://github.com/openai/codex/actions/runs/21980518940/job/63501739210)
    we are not building the shell-tool-mcp job correctly. This one is
    outside my expertise, but seems mostly reasonable.
    
    ## Testing
     - [x] We really need dry runs of these
  • feat(network-proxy): structured policy signaling and attempt correlation to core (#11662)
    ## Summary
    When network requests were blocked, downstream code often had to infer
    ask vs deny from free-form response text. That was brittle and led to
    incorrect approval behavior.
    This PR fixes the proxy side so blocked decisions are structured and
    request metadata survives reliably.
    
    ## Description
    - Blocked proxy responses now carry consistent structured policy
    decision data.
    - Request attempt metadata is preserved across proxy env paths
    (including ALL_PROXY flows).
    - Header stripping was tightened so we still remove unsafe forwarding
    headers, but keep metadata needed for policy handling.
    - Block messages were clarified (for example, allowlist miss vs explicit
    deny).
    - Added unified violation log entries so policy failures can be
    inspected in one place.
    - Added/updated tests for these behaviors.
    
    ---------
    
    Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>
  • fix(ci) lock rust toolchain at 1.93.0 to unblock (#11703)
    ## Summary
    CI is broken on main because our CI toolchain is trying to run 1.93.1
    while our rust toolchain is locked at 1.93.0. I'm sure it's likely safe
    to upgrade, but let's keep things stable for now.
    
    ## Testing
    - [x] CI should hopefully pass
  • chore(core) Restrict model-suggested rules (#11671)
    ## Summary
    If the model suggests a bad rule, don't show it to the user. This does
    not impact the parsing of existing rules, just the ones we show.
    
    ## Testing
    - [x] Added unit tests
    - [x] Ran locally
  • Point Codex App tooltip links to app landing page (#11515)
    ### Motivation
    - Ensure the in-TUI Codex App call-to-action opens the app landing page
    variant `https://chatgpt.com/codex?app-landing-page=true` so users reach
    the intended landing experience.
    
    ### Description
    - Update tooltip constants in `codex-rs/tui/src/tooltips.rs` to replace
    `https://chatgpt.com/codex` with
    `https://chatgpt.com/codex?app-landing-page=true` for the PAID and OTHER
    tooltip variants.
    
    ### Testing
    - Ran `just fmt` in `codex-rs` and `cargo test -p codex-tui`, and the
    test suite completed successfully.
    
    ------
    [Codex
    Task](https://chatgpt.com/codex/tasks/task_i_698d20cf6f088329bb82b07d3ce76e61)
  • fix: dont show NUX for upgrade-target models that are hidden (#11679)
    dont show NUX for models marked with `visibility:hide`.
    
    Tested locally
  • [apps] Fix app loading logic. (#11518)
    When `app/list` is called with `force_refetch=True`, we should seed the
    results with what is already cached instead of starting from an empty
    list. Otherwise when we send app/list/updated events, the client will
    first see an empty list of accessible apps and then get the updated one.
  • chore(approvals) More approvals scenarios (#11660)
    ## Summary
    Add some additional tests to approvals flow
    
    ## Testing
    - [x] these are tests
  • Add cwd as an optional field to thread/list (#11651)
    Add's the ability to filter app-server thread/list by cwd
  • Added a test to verify that feature flags that are enabled by default are stable (#11275)
    We've had a few cases recently where someone enabled a feature flag for
    a feature that's still under development or experimental. This test
    should prevent this.
  • feat(shell-tool-mcp): add patched zsh build pipeline (#11668)
    ## Summary
    - add `shell-tool-mcp/patches/zsh-exec-wrapper.patch` against upstream
    zsh `77045ef899e53b9598bebc5a41db93a548a40ca6`
    - add `zsh-linux` and `zsh-darwin` jobs to
    `.github/workflows/shell-tool-mcp.yml`
    - stage zsh binaries under `artifacts/vendor/<target>/zsh/<variant>/zsh`
    - include zsh artifact jobs in `package.needs`
    - mark staged zsh binaries executable during packaging
    
    ## Notes
    - zsh source is cloned from `https://git.code.sf.net/p/zsh/code`
    - workflow pins zsh commit `77045ef899e53b9598bebc5a41db93a548a40ca6`
    - zsh build runs `./Util/preconfig` before `./configure`
    
    ## Validation
    - parsed workflow YAML locally (`yaml-ok`)
    - validated zsh patch applies cleanly with `git apply --check` on a
    fresh zsh clone
  • Remove git commands from dangerous command checks (#11510)
    ### Motivation
    
    - Git subcommand matching was being classified as "dangerous" and caused
    benign developer workflows (for example `git push --force-with-lease`)
    to be blocked by the preflight policy.
    - The change aligns behavior with the intent to reserve the dangerous
    checklist for truly destructive shell ops (e.g. `rm -rf`) and avoid
    surprising developer-facing blocks.
    
    ### Description
    
    - Remove git-specific subcommand checks from
    `is_dangerous_to_call_with_exec` in
    `codex-rs/shell-command/src/command_safety/is_dangerous_command.rs`,
    leaving only explicit `rm` and `sudo` passthrough checks.
    - Deleted the git-specific helper logic that classified `reset`,
    `branch`-delete, `push` (force/delete/refspec) and `clean --force` as
    dangerous.
    - Updated unit tests in the same file to assert that various `git
    reset`/`git branch`/`git push`/`git clean` variants are no longer
    classified as dangerous.
    - Kept `find_git_subcommand` (used by safe-command classification)
    intact so safe/unsafe parsing elsewhere remains functional.
    
    ### Testing
    
    - Ran formatter with `just fmt` successfully.  
    - Ran unit tests with `cargo test -p codex-shell-command` and all tests
    passed (`144 passed; 0 failed`).
    
    ------
    [Codex
    Task](https://chatgpt.com/codex/tasks/task_i_698d19dedb4883299c3ceb5bbc6a0dcf)
  • Persist complete TurnContextItem state via canonical conversion (#11656)
    ## Summary
    
    This PR delivers the first small, shippable step toward model-visible
    state diffing by making
    `TurnContextItem` more complete and standardizing how it is built.
    
    Specifically, it:
    - Adds persisted network context to `TurnContextItem`.
    - Introduces a single canonical `TurnContext -> TurnContextItem`
    conversion path.
    - Routes existing rollout write sites through that canonical conversion
    helper.
    
    No context injection/diff behavior changes are included in this PR.
    
    ## Why this change
    
    The design goal is to make `TurnContextItem` the canonical source of
    truth for context-diff
    decisions.
    Before this PR:
    - `TurnContextItem` did not include all TurnContext-derived environment
    inputs needed for v1
    completeness.
    - Construction was duplicated at multiple write sites.
    
    This PR addresses both with a minimal, reviewable change.
    
    ## Changes
    
    ### 1) Extend `TurnContextItem` with network state
    - Added `TurnContextNetworkItem { allowed_domains, denied_domains }`.
    - Added `network: Option<TurnContextNetworkItem>` to `TurnContextItem`.
    - Kept backward compatibility by making the new field optional and
    skipped when absent.
    
    Files:
    - `codex-rs/protocol/src/protocol.rs`
    
    ### 2) Canonical conversion helper
    - Added `TurnContext::to_turn_context_item(collaboration_mode)` in core.
    - Added internal helper to derive network fields from
    `config_layer_stack.requirements().network`.
    
    Files:
    - `codex-rs/core/src/codex.rs`
    
    ### 3) Use canonical conversion at rollout write sites
    - Replaced ad hoc `TurnContextItem { ... }` construction with
    `to_turn_context_item(...)` in:
      - sampling request path
      - compaction path
    
    Files:
    - `codex-rs/core/src/codex.rs`
    - `codex-rs/core/src/compact.rs`
    
    ### 4) Update fixtures/tests for new optional field
    - Updated existing `TurnContextItem` literals in tests to include
    `network: None`.
    - Added protocol tests for:
      - deserializing old payloads with no `network`
      - serializing when `network` is present
    
    Files:
    - `codex-rs/core/tests/suite/resume_warning.rs`
    - No replay/diff logic changes.
    - Persisted rollout `TurnContextItem` now carries additional network
    context when available.
    - Older rollout lines without `network` remain readable.
  • Add new apps_mcp_gateway (#11630)
    Adds a new apps_mcp_gateway flag to route Apps MCP calls through
    https://api.openai.com/v1/connectors/mcp/ when enabled, while keeping
    legacy MCP routing as default.
  • [apps] Add is_enabled to app info. (#11417)
    - [x] Add is_enabled to app info and the response of `app/list`.
    - [x] Update TUI to have Enable/Disable button on the app detail page.
  • fix(app-server): surface more helpful errors for json-rpc (#11638)
    Propagate client JSON-RPC errors for app-server request callbacks.
    Previously a number of possible errors were collapsed to `channel
    closed`. Now we should be able to see the underlying client error.
    
    ### Summary
    This change stops masking client JSON-RPC error responses as generic
    callback cancellation in app-server server->client request flows.
    
    Previously, when the client responded with a JSON-RPC error, we removed
    the callback entry but did not send anything to the waiting oneshot
    receiver. Waiters then observed channel closure (for example, auth
    refresh request canceled: channel closed), which hid the actual client
    error.
    
    Now, client JSON-RPC errors are forwarded through the callback channel
    and handled explicitly by request consumers.
    
    ### User-visible behavior
    - External auth refresh now surfaces real client JSON-RPC errors when
    provided.
    - True transport/callback-drop cases still report
    canceled/channel-closed semantics.
    
    ### Example: client JSON-RPC error is now propagated (not masked as
    "canceled")
    
    When app-server asks the client to refresh ChatGPT auth tokens, it sends
    a server->client JSON-RPC request like:
    
    ```json
    {
      "id": 42,
      "method": "account/chatgptAuthTokens/refresh",
      "params": {
        "reason": "unauthorized",
        "previousAccountId": "org-abc"
      }
    }
    ```
    
    If the client cannot refresh and responds with a JSON-RPC error:
    ```
    {
      "id": 42,
      "error": {
        "code": -32000,
        "message": "refresh failed",
        "data": null
      }
    }
    ```
    
    app-server now forwards that error through the callback path and
    surfaces:
    `auth refresh request failed: code=-32000 message=refresh failed`
    
    Previously, this same case could be reported as:
    `auth refresh request canceled: channel closed`
  • app-server: stabilize detached review start on Windows (#11646)
    ## Why
    
    `review_start_with_detached_delivery_returns_new_thread_id` has been
    failing on Windows CI. The failure mode is a process crash
    (`tokio-runtime-worker` stack overflow) during detached review setup,
    which causes EOF in the test harness.
    
    This test is intended to validate detached review thread identity, not
    shell snapshot behavior. We also still want detached review to avoid
    unnecessary rollout-path rediscovery when the parent thread is already
    loaded.
    
    ## What Changed
    
    - Updated detached review startup in
    `codex-rs/app-server/src/codex_message_processor.rs`:
      - `start_detached_review` now receives the loaded parent thread.
      - It prefers `parent_thread.rollout_path()`.
    - It falls back to `find_thread_path_by_id_str(...)` only if the
    in-memory path is unavailable.
    - Hardened the review test fixture in
    `codex-rs/app-server/tests/suite/v2/review.rs` by setting
    `shell_snapshot = false` in test config, so this test no longer depends
    on unrelated Windows PowerShell snapshot initialization.
    
    ## Verification
    
    - `cargo test -p codex-app-server`
    - Verified
    `suite::v2::review::review_start_with_detached_delivery_returns_new_thread_id`
    passes locally.
    
    ## Notes
    
    - Related context: rollout-path lookup behavior changed in #10532.
  • app-server tests: disable shell_snapshot for review suite (#11657)
    ## Why
    
    
    `suite::v2::review::review_start_with_detached_delivery_returns_new_thread_id`
    was failing on Windows CI due to an unrelated process crash during shell
    snapshot initialization (`tokio-runtime-worker` stack overflow).
    
    This review test suite validates review API behavior and should not
    depend on shell snapshot behavior. Keeping shell snapshot enabled in
    this fixture made the test flaky for reasons outside the scenario under
    test.
    
    ## What Changed
    
    - Updated the review suite test config in
    `codex-rs/app-server/tests/suite/v2/review.rs` to set:
      - `shell_snapshot = false`
    
    This keeps the review tests focused on review behavior by disabling
    shell snapshot initialization in this fixture.
    
    ## Verification
    
    - `cargo test -p codex-app-server`
    - Confirmed the previously failing Windows CI job for this test now
    passes on this PR.
  • Add js_repl_tools_only model and routing restrictions (#10671)
    # External (non-OpenAI) Pull Request Requirements
    
    Before opening this Pull Request, please read the dedicated
    "Contributing" markdown file or your PR may be closed:
    https://github.com/openai/codex/blob/main/docs/contributing.md
    
    If your PR conforms to our contribution guidelines, replace this text
    with a detailed and high quality description of your changes.
    
    Include a link to a bug report or enhancement request.
    
    
    #### [git stack](https://github.com/magus/git-stack-cli)
    -  `1` https://github.com/openai/codex/pull/10674
    -  `2` https://github.com/openai/codex/pull/10672
    - 👉 `3` https://github.com/openai/codex/pull/10671
    -  `4` https://github.com/openai/codex/pull/10673
    -  `5` https://github.com/openai/codex/pull/10670
  • [feat] add seatbelt permission files (#11639)
    Add seatbelt permission extension abstraction as permission files for
    seatbelt profiles. This should complement our current sandbox policy
  • docs: require insta snapshot coverage for UI changes (#10669)
    Adds an explicit requirement in AGENTS.md that any user-visible UI
    change includes corresponding insta snapshot coverage and that snapshots
    are reviewed/accepted in the PR.
    
    Tests: N/A (docs only)
  • feat: introduce Permissions (#11633)
    ## Why
    We currently carry multiple permission-related concepts directly on
    `Config` for shell/unified-exec behavior (`approval_policy`,
    `sandbox_policy`, `network`, `shell_environment_policy`,
    `windows_sandbox_mode`).
    
    Consolidating these into one in-memory struct makes permission handling
    easier to reason about and sets up the next step: supporting named
    permission profiles (`[permissions.PROFILE_NAME]`) without changing
    behavior now.
    
    This change is mostly mechanical: it updates existing callsites to go
    through `config.permissions`, but it does not yet refactor those
    callsites to take a single `Permissions` value in places where multiple
    permission fields are still threaded separately.
    
    This PR intentionally **does not** change the on-disk `config.toml`
    format yet and keeps compatibility with legacy config keys.
    
    ## What Changed
    - Introduced `Permissions` in `core/src/config/mod.rs`.
    - Added `Config::permissions` and moved effective runtime permission
    fields under it:
      - `approval_policy`
      - `sandbox_policy`
      - `network`
      - `shell_environment_policy`
      - `windows_sandbox_mode`
    - Updated config loading/building so these effective values are still
    derived from the same existing config inputs and constraints.
    - Updated Windows sandbox helpers/resolution to read/write via
    `permissions`.
    - Threaded the new field through all permission consumers across core
    runtime, app-server, CLI/exec, TUI, and sandbox summary code.
    - Updated affected tests to reference `config.permissions.*`.
    - Renamed the struct/field from
    `EffectivePermissions`/`effective_permissions` to
    `Permissions`/`permissions` and aligned variable naming accordingly.
    
    ## Verification
    - `just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server
    -p codex-exec -p codex-utils-sandbox-summary`
    - `cargo build -p codex-core -p codex-tui -p codex-cli -p
    codex-app-server -p codex-exec -p codex-utils-sandbox-summary`
  • chore(core) Deprecate approval_policy: on-failure (#11631)
    ## Summary
    In an effort to start simplifying our sandbox setup, we're announcing
    this approval_policy as deprecated. In general, it performs worse than
    `on-request`, and we're focusing on making fewer sandbox configurations
    perform much better.
    
    ## Testing
    - [x] Tested locally
    - [x] Existing tests pass
  • add a slash command to grant sandbox read access to inaccessible directories (#11512)
    There is an edge case where a directory is not readable by the sandbox.
    In practice, we've seen very little of it, but it can happen so this
    slash command unlocks users when it does.
    
    Future idea is to make this a tool that the agent knows about so it can
    be more integrated.
  • Add js_repl host helpers and exec end events (#10672)
    ## Summary
    
    This PR adds host-integrated helper APIs for `js_repl` and updates model
    guidance so the agent can use them reliably.
    
    ### What’s included
    
    - Add `codex.tool(name, args?)` in the JS kernel so `js_repl` can call
    normal Codex tools.
    - Keep persistent JS state and scratch-path helpers available:
      - `codex.state`
      - `codex.tmpDir`
    - Wire `js_repl` tool calls through the standard tool router path.
    - Add/align `js_repl` execution completion/end event behavior with
    existing tool logging patterns.
    - Update dynamic prompt injection (`project_doc`) to document:
      - how to call `codex.tool(...)`
      - raw output behavior
    - image flow via `view_image` (`codex.tmpDir` +
    `codex.tool("view_image", ...)`)
    - stdio safety guidance (`console.log` / `codex.tool`, avoid direct
    `process.std*`)
    
    ## Why
    
    - Standardize JS-side tool usage on `codex.tool(...)`
    - Make `js_repl` behavior more consistent with existing tool execution
    and event/logging patterns.
    - Give the model enough runtime guidance to use `js_repl` safely and
    effectively.
    
    ## Testing
    
    - Added/updated unit and runtime tests for:
      - `codex.tool` calls from `js_repl` (including shell/MCP paths)
      - image handoff flow via `view_image`
      - prompt-injection text for `js_repl` guidance
      - execution/end event behavior and related regression coverage
    
    
    
    
    #### [git stack](https://github.com/magus/git-stack-cli)
    -  `1` https://github.com/openai/codex/pull/10674
    - 👉 `2` https://github.com/openai/codex/pull/10672
    -  `3` https://github.com/openai/codex/pull/10671
    -  `4` https://github.com/openai/codex/pull/10673
    -  `5` https://github.com/openai/codex/pull/10670
  • feat(app-server): experimental flag to persist extended history (#11227)
    This PR adds an experimental `persist_extended_history` bool flag to
    app-server thread APIs so rollout logs can retain a richer set of
    EventMsgs for non-lossy Thread > Turn > ThreadItems reconstruction (i.e.
    on `thread/resume`).
    
    ### Motivation
    Today, our rollout recorder only persists a small subset (e.g. user
    message, reasoning, assistant message) of `EventMsg` types, dropping a
    good number (like command exec, file change, etc.) that are important
    for reconstructing full item history for `thread/resume`, `thread/read`,
    and `thread/fork`.
    
    Some clients want to be able to resume a thread without lossiness. This
    lossiness is primarily a UI thing, since what the model sees are
    `ResponseItem` and not `EventMsg`.
    
    ### Approach
    This change introduces an opt-in `persist_full_history` flag to preserve
    those events when you start/resume/fork a thread (defaults to `false`).
    
    This is done by adding an `EventPersistenceMode` to the rollout
    recorder:
    - `Limited` (existing behavior, default)
    - `Extended` (new opt-in behavior)
    
    In `Extended` mode, persist additional `EventMsg` variants needed for
    non-lossy app-server `ThreadItem` reconstruction. We now store the
    following ThreadItems that we didn't before:
    - web search
    - command execution
    - patch/file changes
    - MCP tool calls
    - image view calls
    - collab tool outcomes
    - context compaction
    - review mode enter/exit
    
    For **command executions** in particular, we truncate the output using
    the existing `truncate_text` from core to store an upper bound of 10,000
    bytes, which is also the default value for truncating tool outputs shown
    to the model. This keeps the size of the rollout file and command
    execution items returned over the wire reasonable.
    
    And we also persist `EventMsg::Error` which we can now map back to the
    Turn's status and populates the Turn's error metadata.
    
    #### Updates to EventMsgs
    To truly make `thread/resume` non-lossy, we also needed to persist the
    `status` on `EventMsg::CommandExecutionEndEvent` and
    `EventMsg::PatchApplyEndEvent`. Previously it was not obvious whether a
    command failed or was declined (similar for apply_patch). These
    EventMsgs were never persisted before so I made it a required field.
  • Parse first order skill/connector mentions (#11547)
    This PR introduces a skill-expansion mechanism for mentions so nested or
    skill or connection mentions are expanded if present in skills invoked
    by the user. This keeps behavior aligned with existing mention handling
    while extending coverage to deeper scenarios. With these changes, users
    can create skills that invoke connectors, and skills that invoke other
    skills.
    
    Replaces #10863, which is not needed with the addition of
    [search_tool_bm25](https://github.com/openai/codex/issues/10657)
  • Add cwd to memory files (#11591)
    Add cwd to memory files so that model can deal with multi cwd memory
    better.
    
    ---------
    
    Co-authored-by: jif-oai <jif@openai.com>