pakrym-oai

This commit provides a **bug fix** and **refactoring** to correctly normalize `/mcp` tool grouping, specifically addressing issues with **hyphenated server names** and other special characters. It introduces new core logic within the **`codex-rs/core/src/mcp` module** to sanitize tool names for the Responses API and generate qualified prefixes using `sanitize_responses_api_tool_name` and `qualified_mcp_tool_name_prefix`. The `sanitize_responses_api_tool_name` function was also **refactored** to its proper module for better organization. The **`tui` and `tui_app_server` user interface components** are updated to leverage this new logic in `new_mcp_tools_output`, ensuring accurate display and grouping of tools in the history cell. This change improves the robustness of the `mcp` tool display for servers with non-standard naming conventions.

This commit introduces a **new capability** by implementing a **cached `EnvironmentManager`** to centralize and standardize the management of the execution server URL. This **singleton manager** is initialized early in the **`app-server`** and **`mcp-server`** components, leveraging an environment variable (`CODEX_EXEC_SERVER_URL_ENV_VAR`) for configuration. It is deeply integrated across **`codex-rs/core`** components such as `MessageProcessor`, `Codex`, `Session`, and `ThreadManager`, replacing previous direct `Environment` creation. This **refactoring** streamlines environment handling, improves consistency across the application, and updates numerous **test harnesses** to utilize the new manager, alongside new scripts for running the **TUI** with an exec server.

This commit undertakes a significant **refactoring** effort to migrate the `cwd` (current working directory) state across the **`codex-rs/core`**, **`app-server`**, and **`tui`** modules to consistently use `AbsolutePathBuf`. This ensures that all downstream consumers reliably receive absolute paths, thereby improving path resolution and reducing ambiguity. The work involved updating numerous internal components like `TurnContext`, `SessionConfiguration`, and `Config` to handle the new type, alongside adjusting path joining and comparison logic. Additionally, new test-only `.abs()` helpers were introduced for `Path`, `PathBuf`, and `TempDir` to streamline `AbsolutePathBuf` creation in tests, and snapshot tests were carefully updated to accommodate platform-specific absolute path formats.

This commit **refactors** the **sandboxing execution request** mechanism by **removing the `sandbox_permissions` field** from `ExecOptions` and `ExecRequest` types. It eliminates the now-unused plumbing for these permissions from various call sites, including the **shell**, **unified exec**, **JS REPL**, and **apply-patch runtime**. The `codex-rs/core/src/exec.rs` module's `build_exec_request` and `execute_exec_request` functions are updated to default `ExecParams` to `SandboxPermissions::UseDefault` where the lower-level API still requires this field. This change **simplifies the execution API** by centralizing the default handling of sandbox permissions, making the system cleaner and less prone to permission propagation errors.

This commit performs a significant **architectural refactoring** by **extracting all core sandbox management and command transformation logic** into a new, dedicated `codex-sandboxing` crate. This new crate now centralizes critical components such as `SandboxType`, `SandboxManager`, `SandboxCommand`, and `SandboxTransformRequest`. Consequently, various parts of the **`codex-rs/core` module**, including the main execution logic (`exec.rs`), several runtime tools, and the `app-server`, have been updated to consume these newly externalized components. This change enhances modularity, reusability, and maintainability of the sandboxing infrastructure across the project.

This commit performs a significant **refactoring** by **moving** the core logic for **sandbox policy transformations** from the **`codex-core`** crate into a new `policy_transforms` module within the **`codex-sandboxing`** crate. This change improves **modularity** and **separation of concerns**, centralizing all sandboxing-related utilities. Consequently, modules in **`codex-core`** and **`codex-app-server`** that utilize these functions have been updated to import them directly from `codex-sandboxing`, and all corresponding unit tests were also relocated to maintain test coverage. The `SandboxManager::transform` method in `codex-core` now delegates to these newly moved functions, streamlining the sandboxing architecture.

This commit performs a significant **refactoring** by **relocating all macOS sandboxing logic** from the `codex-core` crate into the more appropriate `codex-sandboxing` crate. This includes moving seatbelt policy builders, permission merging/intersection logic, SBPL assets, and their associated tests, thereby centralizing the **macOS sandboxing implementation**. The `codex-core` crate is simplified to only retain the `spawn_command_under_seatbelt` wrapper, with all internal call sites updated to import the moved APIs directly. This change enhances **modularity** and improves the organization of platform-specific sandboxing components within the project.

This commit **refactors** the project by extracting Linux-specific sandboxing helper functions, including `allow_network_for_proxy` and `create_linux_sandbox_command_args_for_policies`, into a new dedicated **`codex-sandboxing`** crate. This move significantly reduces the sandboxing implementation footprint within **`codex-core`** and updates direct callers in `codex-cli` to use the new module. The change is a **code organization** effort aimed at improving **modularity** and separation of concerns. It isolates the sandboxing logic, making it more maintainable and preparing the groundwork for future sandboxing enhancements without altering the current runtime behavior.

This commit introduces the **new capability** for `codex` to execute tests remotely, significantly enhancing its testing infrastructure. It adds the `remote-tests` skill, complete with **documentation** in `.codex/skills/remote-tests/SKILL.md` that explains how to run tests using a remote executor. Concurrently, it **refactors image-related tests** within `codex-rs/core/tests/suite/view_image.rs` by adding helper functions for creating and writing image files in the workspace. Existing tests are updated to leverage a **remote-aware test builder**, ensuring compatibility and readiness for distributed execution.

This commit introduces a **new capability** to run `codex-rs` integration tests within a **remote Docker environment**, significantly enhancing the project's testing infrastructure. By setting `CODEX_TEST_REMOTE_ENV`, existing tests can now execute "remotely" via a managed Docker container and a remote execution server, improving test isolation and realism. The **CI/CD workflow** (`.github/workflows/rust-ci.yml`) is updated to include a new matrix entry for these remote tests, while core test utilities in `codex-rs/core/tests/common/test_codex.rs` and a new script `scripts/test-remote-env.sh` manage the remote environment's lifecycle. This **CI/CD enhancement** and **testing infrastructure refactoring** ensures broader and more reliable test coverage for the `codex-rs` core.

This commit introduces a significant **refactoring** of the `ExecServer`'s filesystem handling, abstracting operations with the new `ExecutorFileSystem` trait defined in `codex-rs/exec-server/src/file_system.rs`. It provides distinct **local** (`LocalFileSystem`) and **remote** (`RemoteFileSystem`) implementations, with the `ExecServer`'s environment dynamically selecting the appropriate one via `get_filesystem`. This **new capability** allows the `ExecServer` to proxy filesystem operations over the network, enhancing its flexibility for distributed execution. The `FsApi` and `FileSystemHandler` are updated to utilize this new abstraction, ensuring that both local and remote filesystem access is managed consistently. Comprehensive tests for `ExecutorFileSystem` have been added to validate the new architecture.

This commit introduces an **experimental capability** to configure and connect to an external execution server. It **extends the core configuration system** by adding an `experimental_exec_server_url` field to the `Config` structs and schema, allowing users to specify a remote execution server. The **`exec-server` module's `Environment`** is refactored to support this URL, including a new `create` method that encapsulates connection logic. This new `Environment::create` method is then integrated into **session initialization** and `FsApi` instantiation, enabling the system to attempt starting the server based on the configured URL. The change is supported by **new and updated tests** ensuring proper configuration loading and environment setup.

This commit performs a significant **architectural refactoring** by **relocating the `Environment` abstraction** and its associated traits, such as `ExecutorFileSystem`, into the **`codex-exec-server` crate**. This change centralizes the definition of the execution environment within the module responsible for its implementation, whether local or remote. Consequently, modules like **`codex-core`** and **`codex-app-server`** have their import paths updated to reflect the new location, ensuring they remain decoupled from the environment's concrete backing. This improves modularity and clarifies the ownership of the environment services, making the `core` module agnostic to the underlying execution details.

This commit **removes the deprecated stdio transport** from the **`exec-server`**, streamlining its communication mechanism to rely solely on websockets. It involves a significant **refactoring** of the server's transport layer, including the removal of the `ExecServerTransport` enum and adaptation of server entry points to use listen URLs. Additionally, **new test infrastructure** such as `ExecServerHarness` is introduced to facilitate robust testing of the websocket-based server, ensuring proper handling of requests and malformed JSON. This **maintenance** and **refactoring** effort simplifies the server's architecture, improves its maintainability by eliminating legacy code, and updates documentation to reflect the new flow. The `stdio` connection functions are now restricted to test environments.

This commit introduces a **new capability** within the **`codex-rs/core` module** by adding a `code_mode_result` to the output of the `apply_patch` tool. It defines a new `ApplyPatchToolOutput` struct in `codex-rs/core/src/tools/context.rs` and implements the `ToolOutput` trait, providing a `code_mode_result` method that returns an empty JSON object. The **`ApplyPatchHandler`** in `codex-rs/core/src/tools/handlers/apply_patch.rs` is updated to utilize this new output type, ensuring the `apply_patch` tool can now provide structured results. A new test case verifies that the `apply_patch` code mode result is indeed an empty JSON object, confirming the expected behavior of this **tool output enhancement**.

This commit **introduces a new capability** to the **`codex-rs/core`** module by defining the specific output behavior for the **`update_plan` tool** when operating in "code mode". It establishes that the `code_mode_result` for this tool will consistently be an **empty object**, implemented via the new `PlanToolOutput` structure within `codex-rs/core/src/tools/handlers/plan.rs`. This change standardizes the output format, ensuring predictable results for any system consuming the `update_plan` tool's output in this particular mode. A **new test case** has been added to `codex-rs/core/tests/suite/code_mode.rs` to explicitly verify this expected empty object result.

This commit introduces a **significant enhancement** to the **`codex-rs/core`** module by standardizing image data handling within **`code_mode`**. The `view_image` tool now returns a structured object `{image_url: string, details?: string}` instead of a plain URL, providing richer context for displayed images. Consequently, the `image()` helper has been **refactored** to seamlessly accept both string URLs and this new structured output, improving interoperability. Additionally, **image processing error handling** in `codex-rs/utils/image` has been refined with more specific error types, leading to clearer diagnostics for unsupported image formats. This update improves the overall **image semantics** and robustness of the system.

This commit **refactors** the **tooling subsystem** to **propagate `FunctionCallError` directly** through the call stack, ensuring that specific tool execution errors are not lost. It modifies **code mode**'s internal communication protocol (`protocol.rs`, `runner.cjs`, `worker.rs`) to include an `error_text` field, allowing nested tool call failures to be surfaced as exceptions within the code mode execution environment. This **enhances error reporting** by providing more granular and actionable feedback when tools fail, impacting the `js_repl` and `parallel` tool execution, and is validated by updated and new **tests**.

This commit introduces a **new capability** to the **code-mode** environment, enabling models to send **out-of-band notifications** through a new `notify` function. These notifications are processed by the **`codex-rs/core`** module and injected as custom tool call outputs, enhancing real-time feedback and interactivity. To facilitate this, the **`codex-rs/app-server-protocol`** and **`codex-rs/protocol`** schemas are updated to include an optional `name` field for `FunctionCallOutput`, and the **`code-mode`** internal protocol and worker logic are **refactored** to process these new `Notify` messages. This allows for more dynamic communication from the model, improving the overall user experience within **code-mode**.

This commit **refactors** the **websocket enablement logic** across the `codex-rs` core client and related modules. It **removes all legacy feature flags** (`ResponsesWebsockets`, `ResponsesWebsocketsV2`) that previously controlled websocket usage, simplifying the system by relying solely on whether the **model provider explicitly supports websockets**. This **maintenance** effort streamlines the client's connection strategy, ensuring websockets are preferred when supported by the provider, and significantly updates numerous **test suites** to reflect this new, capability-driven approach.