Developer
iceweasel-oai
iceweasel@openai.com
Performance
Key patterns and highlights from this developer's activity.
Breakdown of growth, maintenance, and fixes effort over time.
Bugs introduced vs. fixed over time.
Reclassifies engineering effort based on bug attribution. Commits that introduced bugs are retrospectively counted as poor investments.
Investment Quality reclassifies engineering effort based on bug attribution data. Commits identified as buggy origins (those that introduced bugs later fixed by someone) have their grow and maintenance time moved into the Wasted Time category. Their waste (fix commits) remains counted as productive. All other commits retain their standard classification: grow is productive, maintenance is maintenance, and waste (fixes) is productive.
The standard model classifies commits as Growth, Maintenance, or Fixes. Investment Quality adds a quality lens: a commit that introduced a bug is retrospectively counted as a poor investment — the engineering time spent on it was wasted because it ultimately required additional fix work. Fix commits (Fixes in the standard model) are reframed as productive, because fixing bugs is valuable work.
Currently computed client-side from commit and bug attribution data. Ideal server-side endpoint:
POST /v1/organizations/{orgId}/investment-quality
Content-Type: application/json
Request:
{
"startTime": "2025-01-01T00:00:00Z",
"endTime": "2025-12-31T23:59:59Z",
"bucketSize": "BUCKET_SIZE_MONTH",
"groupBy": ["repository_id" | "deliverer_email"]
}
Response:
{
"productivePct": 74,
"maintenancePct": 18,
"wastedPct": 8,
"buckets": [
{
"bucketStart": "2025-01-01T00:00:00Z",
"productive": 4.2,
"maintenance": 1.8,
"wasted": 0.6
}
]
}Latest analyzed commits from this developer.
| Hash | Message | Date | Files |
|---|
Commit activity distribution by hour and day of week. Shows when this developer is most active.
Developers who frequently work on the same files and symbols. Higher score means stronger code collaboration.
| Effort |
|---|
| 307e427a | This commit **optimizes the `apply_patch` functionality** within the `codex-rs/core` module by preventing the inclusion of redundant write roots. It introduces a **bug fix** and **performance improvement** by modifying the `write_permissions_for_paths` function to filter out paths that are already writable by the file system sandbox policy. This change specifically addresses and avoids unnecessary ACL churn and potential failures observed on **Windows systems**, where redundant permission modifications can cause issues. By streamlining the write root determination, the commit enhances the stability and efficiency of patch application. New test cases have been added to `apply_patch_tests.rs` to validate this corrected behavior. | Mar 27 | 2 | waste |
| 69750a0b | This commit **enhances the `exec_command`, `shell`, and `shell_command` tools** within the **`codex-rs/core/src/tools` module** by integrating specific **Windows safety guidance** into their descriptions. This **feature improvement** provides critical advice for handling destructive filesystem operations, such as avoiding cross-shell command composition and verifying target paths before recursive deletes or moves. The new guidance aims to prevent accidental data loss and improve the robustness of command execution for users operating in a **Windows environment**. This update ensures that users are explicitly warned about potential pitfalls, thereby enhancing the overall safety and usability of these tools. Corresponding tests were also added to verify the correct inclusion of this safety information. | Mar 19 | 2 | grow |
| 2cc4ee41 | This commit introduces a **temporary workaround** within the **Windows sandbox IPC mechanism** to address an incompatibility. It **disables the `use_private_desktop` feature** by hardcoding its flag to `false` specifically when the `spawn_ipc_process` function is invoked for an **elevated IPC path** in `codex-rs/windows-sandbox-rs/src/elevated/command_runner_win.rs`. This **maintenance change** prevents potential issues and ensures stability for users of the **Windows sandbox** until the private desktop functionality is fully compatible with elevated IPC processes. | Mar 17 | 1 | waste |
| 95bdea93 | This commit **refactors** the **Windows elevated sandbox command runner** to utilize a **new framed IPC transport**, replacing the legacy request-file bootstrap mechanism for one-shot executions. Specifically, `elevated_impl.rs` is updated to launch the runner with named pipes and process framed `SpawnRequest` and `Output`/`Exit` messages, while `command_runner_win.rs` removes the old execution path. This **infrastructure upgrade** is a crucial step in preparing the **Windows sandbox** for future **unified_exec** capabilities, establishing a robust communication channel across security contexts. Although the public behavior remains one-shot, this change lays the groundwork for long-lived bidirectional communication, addressing the unique challenges of elevated sandboxing on Windows. | Mar 17 | 5 | maint |
| d0a693e5 | This commit lays the **foundational infrastructure** for future `unified_exec` capabilities within the **Windows elevated sandbox**. It introduces a **new IPC transport layer** and associated plumbing, including **framed message types** in `ipc_framed.rs`, **named pipe helpers** in `runner_pipe.rs`, and **ConPTY management utilities** in the new `conpty/` module, to enable long-lived, bidirectional communication with a helper process. While this is a **new capability** that significantly refactors the `command_runner_win.rs` and related modules, it intentionally **does not yet alter production behavior**, serving as a preparatory step for subsequent changes that will switch to this new IPC-based execution path. The work also includes a **significant source-layout cleanup** to organize Windows sandbox files into explicit `elevated/`, `conpty/`, and shared locations, streamlining future development. | Mar 16 | 18 | grow |
| 6b3d82da | This commit implements a **critical security enhancement** for **Windows sandboxing**, ensuring that all sandboxed processes now launch on a dedicated, private desktop instead of the shared `Winsta0\Default`. This **new capability** significantly reduces the attack surface by preventing UI/input interaction and spoofing from sandboxed applications. The change involves **refactoring** the core process creation logic within `windows-sandbox-rs`, centralizing launches through `create_process_as_user` and introducing a new `desktop.rs` module for private desktop management. Enabled by default, users can control this behavior via the new `windows.sandbox_private_desktop` configuration setting, which acts as an explicit opt-out. This improves the overall **security posture** of sandboxed command execution on Windows. | Mar 13 | 30 | grow |
| fa265976 | This commit implements a **security fix** by preventing the use of `unified_exec` within sandboxed environments on **Windows**, addressing a critical issue where it could bypass sandbox restrictions. The **`codex-rs/core`** module's **tool configuration** logic, particularly in `codex-rs/core/src/tools/spec.rs`, was updated to enforce this restriction by checking the sandbox policy and Windows sandbox level. This **bug fix** enhances the **security posture** of the application on Windows, ensuring sandbox integrity until `unified_exec` officially supports the Windows Sandbox. Associated **refactoring** in `codex-rs/core/src/codex.rs` passes the necessary sandbox parameters, and new tests in `codex-rs/core/src/tools/spec_tests.rs` validate the correct blocking of `unified_exec`. | Mar 12 | 3 | maint |
| 4b4f61d3 | This commit introduces a **validation enhancement** to the **`app-server`** by strictly requiring an absolute path for the `cwd` parameter in the **`windowsSandbox/setupStart`** RPC call. It **refactors** the **`app-server-protocol`** schemas and Rust types to enforce `AbsolutePathBuf`, ensuring that any relative `cwd` values are rejected at the RPC layer during request parsing. This change eliminates potential ambiguity and divergence between `command_cwd` and `policy_cwd` during Windows sandbox setup, providing a single, validated absolute path to the handler. The update includes **documentation updates** in `app-server/README.md` and **new test coverage** to ensure robust input handling. | Mar 7 | 9 | maint |
| 8ede1801 | This commit introduces a **new feature** to the project's **CI/CD pipeline** by adding an automated **WinGet publication step** for stable **CLI releases**. A new job named `winget` is integrated into the `.github/workflows/rust-release.yml` GitHub Actions workflow, which automatically publishes the CLI to WinGet. This significantly **enhances the release process** by leveraging `vedantmgoyal9/winget-releaser` to reduce manual effort and boilerplate. The change ensures that Windows users can easily install and update the **CLI** via **WinGet**, improving distribution and user experience. | Mar 6 | 1 | grow |
| 14de4929 | This commit **fixes a critical issue** preventing **Windows sandbox users** from successfully running the `apply_patch` runtime. Previously, `codex.exe` and `codex-command-runner.exe` could not be executed from the restricted `WindowsApp/` directory within the sandbox, causing patch applications to fail. A new public function, `resolve_current_exe_for_launch`, has been added to the **`windows-sandbox-rs` crate** to **copy the current executable to a sandbox-friendly location** (`CODEX_HOME/.sandbox-bin`) before launch. This ensures that core `codex` operations, particularly those involving `apply_patch`, function correctly for users operating within the Windows sandbox environment. | Mar 6 | 3 | waste |
| 54a1c81d | This commit introduces a **new capability** allowing client applications to specify a current working directory (`cwd`) for **Windows sandbox setup**. Previously, the sandbox setup defaulted to the app's installation directory, causing slow initial shell commands due to incorrect ACL configuration. The **`app-server-protocol`** is updated to include an optional `cwd` parameter within `WindowsSandboxSetupStartParams` across its JSON schemas, TypeScript types, and Rust structs. The **`app-server`**'s `handle_windows_sandbox_setup_start_request` is modified to process this parameter, ensuring ACLs are correctly established in the intended project workspace. This **performance improvement** prevents initial delays for downstream applications by allowing them to properly configure the sandbox environment. | Mar 4 | 9 | maint |
| 639a5f6c | This commit introduces a **new helper materialization mechanism** to **fix reliability issues** with **Windows sandbox runner launches**, specifically for `codex-command-runner.exe`. It ensures the runner is always executable by copying it to a secure, user-owned location (`CODEX_HOME/.sandbox-bin/`) with strict ACLs, falling back to the original path if necessary. This involves a **new `helper_materialization` module** for managing and caching these binaries, alongside **refactoring** in `elevated_impl.rs` for runner lookup and `setup_orchestrator.rs` for securing the new `sandbox_bin_dir`. The change significantly **improves the robustness and security** of **Windows sandbox operations** by providing a reliable and controlled execution environment for critical helper executables. | Mar 4 | 7 | grow |
| 6b879fe2 | This commit introduces a **security hardening** measure within the **`windows-sandbox-rs`** component by preventing the sandbox from gaining read access to sensitive user profile directories. It adds a new function, `profile_read_roots`, to the `setup_orchestrator.rs` module, which filters out paths like `~/.ssh` from the sandbox's allowed read roots. This **resolves an issue** where OpenSSH would complain about overly permissive access to SSH keys, improving the overall **security posture** of the sandbox. The change ensures that sensitive user data is not inadvertently exposed within the sandboxed environment. | Feb 26 | 1 | waste |
| 29254261 | This commit introduces a **new capability** to the **app-server** for initiating and managing **Windows sandbox setup**. It extends the `app-server-protocol` by defining new JSON and TypeScript schemas for a `windowsSandbox/setupStart` client request and a `windowsSandbox/setupCompleted` server notification, enabling asynchronous communication. The `app-server` now includes a handler for this request, which processes the setup using core logic within `codex-rs/core/src/windows_sandbox.rs` and sends a notification back to the client upon completion. This foundational work establishes the server-side orchestration for Windows sandbox environments, with future UI integration planned to utilize this new protocol. | Feb 18 | 21 | grow |
| c4bb7db1 | This commit **improves the robustness of the CI/CD pipeline** by modifying the **Rust release workflow**. Specifically, it updates the `npm publish` step in `.github/workflows/rust-release.yml` to **gracefully handle attempts to publish an already existing package version**. This **maintenance** change prevents the workflow from failing in such scenarios, ensuring a more resilient and idempotent release automation process for npm packages. | Feb 17 | 1 | maint |
| 99466f1f | This commit **updates telemetry and event handling** within the **TUI (Text User Interface)** to align with recent NUX (New User Experience) adjustments for the **Windows Sandbox fallback mechanism**. It **refactors** the `OpenWindowsSandboxFallbackPrompt` event by removing the `WindowsSandboxFallbackReason` enum and its associated `reason` parameter, streamlining event processing in `handle_app_event`. Additionally, it **updates OpenTelemetry metric names** related to Windows Sandbox prompts and introduces a new metric to track legacy setup preflight failures, ensuring more accurate and relevant usage data collection for the setup process. | Feb 13 | 3 | maint |
| 5c3ca739 | This commit introduces a **new capability** to the **Windows sandbox integration** by allowing users to grant read access to previously inaccessible directories. It adds a new **slash command**, `/sandbox-add-read-dir`, to the **TUI** for manually specifying additional read roots. This addresses an edge case where the sandbox might fail to read certain paths, improving the overall robustness and user experience of the **sandbox environment**. The core library now includes new modules and functions like `grant_read_root_non_elevated` and `run_setup_refresh_with_extra_read_roots` to manage these permissions, enabling users to resolve sandbox access issues directly. | Feb 12 | 9 | grow |
| 87279de4 | This commit significantly **refactors** and **enhances the user experience** for the **Windows Sandbox** feature, centralizing its configuration and streamlining the onboarding process. It introduces a new `windows.sandbox` configuration key, replacing legacy feature flags, and simplifies the NUX by moving it after the trust directory screen, removing the "read-only" option, and enforcing a "trust or quit" decision for untrusted directories. This change impacts the **core configuration system**, the **TUI onboarding flow**, and the **chat widget**, providing a clearer and more direct path for users to enable and configure the Windows Sandbox. The update also includes **maintenance** to handle legacy sandbox configurations and renames the `/setup-elevated-sandbox` command to `/setup-default-sandbox`. | Feb 11 | 21 | maint |
| 82f93a13 | This commit introduces a **new capability** to include sandbox environment information, such as "seatbelt" or "elevated" modes, directly within the **turn metadata header**. A new `sandbox_tags` module was added to `codex-rs/core` to centralize the logic for determining the appropriate sandbox tag, which is then integrated into the `build_turn_metadata_header` function and `Session::new`. This enhancement to the **telemetry system** provides crucial data for understanding user retention and usage patterns, particularly for users operating within various sandboxed environments. The change also involved **refactoring** existing sandbox tag logic from `codex-rs/core/src/tools/registry.rs` to utilize the new dedicated module, ensuring consistency and maintainability. | Feb 10 | 6 | grow |
| 901d5b8f | This commit introduces a **new capability** to enhance **observability** by adding **sandbox policy and name details** to `codex.tool.call` metrics. It modifies the **core tool execution registry** (`codex-rs/core/src/tools/registry.rs`) to capture this information during `handle_tool_call` and integrates it into the **OpenTelemetry tracing and metrics system** via `otel_manager.rs`. This allows for granular tracking of tool call outcomes, providing crucial **visibility into the comparative success rates of various sandbox implementations**, especially for Windows, to inform future performance and reliability improvements. The change also includes a new `as_metric_tag` method for `SandboxType` in `exec.rs` and updates a test case in the OpenTelemetry suite. | Feb 5 | 4 | grow |
This commit **optimizes the `apply_patch` functionality** within the `codex-rs/core` module by preventing the inclusion of redundant write roots. It introduces a **bug fix** and **performance improvement** by modifying the `write_permissions_for_paths` function to filter out paths that are already writable by the file system sandbox policy. This change specifically addresses and avoids unnecessary ACL churn and potential failures observed on **Windows systems**, where redundant permission modifications can cause issues. By streamlining the write root determination, the commit enhances the stability and efficiency of patch application. New test cases have been added to `apply_patch_tests.rs` to validate this corrected behavior.
This commit **enhances the `exec_command`, `shell`, and `shell_command` tools** within the **`codex-rs/core/src/tools` module** by integrating specific **Windows safety guidance** into their descriptions. This **feature improvement** provides critical advice for handling destructive filesystem operations, such as avoiding cross-shell command composition and verifying target paths before recursive deletes or moves. The new guidance aims to prevent accidental data loss and improve the robustness of command execution for users operating in a **Windows environment**. This update ensures that users are explicitly warned about potential pitfalls, thereby enhancing the overall safety and usability of these tools. Corresponding tests were also added to verify the correct inclusion of this safety information.
This commit introduces a **temporary workaround** within the **Windows sandbox IPC mechanism** to address an incompatibility. It **disables the `use_private_desktop` feature** by hardcoding its flag to `false` specifically when the `spawn_ipc_process` function is invoked for an **elevated IPC path** in `codex-rs/windows-sandbox-rs/src/elevated/command_runner_win.rs`. This **maintenance change** prevents potential issues and ensures stability for users of the **Windows sandbox** until the private desktop functionality is fully compatible with elevated IPC processes.
This commit **refactors** the **Windows elevated sandbox command runner** to utilize a **new framed IPC transport**, replacing the legacy request-file bootstrap mechanism for one-shot executions. Specifically, `elevated_impl.rs` is updated to launch the runner with named pipes and process framed `SpawnRequest` and `Output`/`Exit` messages, while `command_runner_win.rs` removes the old execution path. This **infrastructure upgrade** is a crucial step in preparing the **Windows sandbox** for future **unified_exec** capabilities, establishing a robust communication channel across security contexts. Although the public behavior remains one-shot, this change lays the groundwork for long-lived bidirectional communication, addressing the unique challenges of elevated sandboxing on Windows.
This commit lays the **foundational infrastructure** for future `unified_exec` capabilities within the **Windows elevated sandbox**. It introduces a **new IPC transport layer** and associated plumbing, including **framed message types** in `ipc_framed.rs`, **named pipe helpers** in `runner_pipe.rs`, and **ConPTY management utilities** in the new `conpty/` module, to enable long-lived, bidirectional communication with a helper process. While this is a **new capability** that significantly refactors the `command_runner_win.rs` and related modules, it intentionally **does not yet alter production behavior**, serving as a preparatory step for subsequent changes that will switch to this new IPC-based execution path. The work also includes a **significant source-layout cleanup** to organize Windows sandbox files into explicit `elevated/`, `conpty/`, and shared locations, streamlining future development.
This commit implements a **critical security enhancement** for **Windows sandboxing**, ensuring that all sandboxed processes now launch on a dedicated, private desktop instead of the shared `Winsta0\Default`. This **new capability** significantly reduces the attack surface by preventing UI/input interaction and spoofing from sandboxed applications. The change involves **refactoring** the core process creation logic within `windows-sandbox-rs`, centralizing launches through `create_process_as_user` and introducing a new `desktop.rs` module for private desktop management. Enabled by default, users can control this behavior via the new `windows.sandbox_private_desktop` configuration setting, which acts as an explicit opt-out. This improves the overall **security posture** of sandboxed command execution on Windows.
This commit implements a **security fix** by preventing the use of `unified_exec` within sandboxed environments on **Windows**, addressing a critical issue where it could bypass sandbox restrictions. The **`codex-rs/core`** module's **tool configuration** logic, particularly in `codex-rs/core/src/tools/spec.rs`, was updated to enforce this restriction by checking the sandbox policy and Windows sandbox level. This **bug fix** enhances the **security posture** of the application on Windows, ensuring sandbox integrity until `unified_exec` officially supports the Windows Sandbox. Associated **refactoring** in `codex-rs/core/src/codex.rs` passes the necessary sandbox parameters, and new tests in `codex-rs/core/src/tools/spec_tests.rs` validate the correct blocking of `unified_exec`.
This commit introduces a **validation enhancement** to the **`app-server`** by strictly requiring an absolute path for the `cwd` parameter in the **`windowsSandbox/setupStart`** RPC call. It **refactors** the **`app-server-protocol`** schemas and Rust types to enforce `AbsolutePathBuf`, ensuring that any relative `cwd` values are rejected at the RPC layer during request parsing. This change eliminates potential ambiguity and divergence between `command_cwd` and `policy_cwd` during Windows sandbox setup, providing a single, validated absolute path to the handler. The update includes **documentation updates** in `app-server/README.md` and **new test coverage** to ensure robust input handling.
This commit introduces a **new feature** to the project's **CI/CD pipeline** by adding an automated **WinGet publication step** for stable **CLI releases**. A new job named `winget` is integrated into the `.github/workflows/rust-release.yml` GitHub Actions workflow, which automatically publishes the CLI to WinGet. This significantly **enhances the release process** by leveraging `vedantmgoyal9/winget-releaser` to reduce manual effort and boilerplate. The change ensures that Windows users can easily install and update the **CLI** via **WinGet**, improving distribution and user experience.
This commit **fixes a critical issue** preventing **Windows sandbox users** from successfully running the `apply_patch` runtime. Previously, `codex.exe` and `codex-command-runner.exe` could not be executed from the restricted `WindowsApp/` directory within the sandbox, causing patch applications to fail. A new public function, `resolve_current_exe_for_launch`, has been added to the **`windows-sandbox-rs` crate** to **copy the current executable to a sandbox-friendly location** (`CODEX_HOME/.sandbox-bin`) before launch. This ensures that core `codex` operations, particularly those involving `apply_patch`, function correctly for users operating within the Windows sandbox environment.
This commit introduces a **new capability** allowing client applications to specify a current working directory (`cwd`) for **Windows sandbox setup**. Previously, the sandbox setup defaulted to the app's installation directory, causing slow initial shell commands due to incorrect ACL configuration. The **`app-server-protocol`** is updated to include an optional `cwd` parameter within `WindowsSandboxSetupStartParams` across its JSON schemas, TypeScript types, and Rust structs. The **`app-server`**'s `handle_windows_sandbox_setup_start_request` is modified to process this parameter, ensuring ACLs are correctly established in the intended project workspace. This **performance improvement** prevents initial delays for downstream applications by allowing them to properly configure the sandbox environment.
This commit introduces a **new helper materialization mechanism** to **fix reliability issues** with **Windows sandbox runner launches**, specifically for `codex-command-runner.exe`. It ensures the runner is always executable by copying it to a secure, user-owned location (`CODEX_HOME/.sandbox-bin/`) with strict ACLs, falling back to the original path if necessary. This involves a **new `helper_materialization` module** for managing and caching these binaries, alongside **refactoring** in `elevated_impl.rs` for runner lookup and `setup_orchestrator.rs` for securing the new `sandbox_bin_dir`. The change significantly **improves the robustness and security** of **Windows sandbox operations** by providing a reliable and controlled execution environment for critical helper executables.
This commit introduces a **security hardening** measure within the **`windows-sandbox-rs`** component by preventing the sandbox from gaining read access to sensitive user profile directories. It adds a new function, `profile_read_roots`, to the `setup_orchestrator.rs` module, which filters out paths like `~/.ssh` from the sandbox's allowed read roots. This **resolves an issue** where OpenSSH would complain about overly permissive access to SSH keys, improving the overall **security posture** of the sandbox. The change ensures that sensitive user data is not inadvertently exposed within the sandboxed environment.
This commit introduces a **new capability** to the **app-server** for initiating and managing **Windows sandbox setup**. It extends the `app-server-protocol` by defining new JSON and TypeScript schemas for a `windowsSandbox/setupStart` client request and a `windowsSandbox/setupCompleted` server notification, enabling asynchronous communication. The `app-server` now includes a handler for this request, which processes the setup using core logic within `codex-rs/core/src/windows_sandbox.rs` and sends a notification back to the client upon completion. This foundational work establishes the server-side orchestration for Windows sandbox environments, with future UI integration planned to utilize this new protocol.
This commit **improves the robustness of the CI/CD pipeline** by modifying the **Rust release workflow**. Specifically, it updates the `npm publish` step in `.github/workflows/rust-release.yml` to **gracefully handle attempts to publish an already existing package version**. This **maintenance** change prevents the workflow from failing in such scenarios, ensuring a more resilient and idempotent release automation process for npm packages.
This commit **updates telemetry and event handling** within the **TUI (Text User Interface)** to align with recent NUX (New User Experience) adjustments for the **Windows Sandbox fallback mechanism**. It **refactors** the `OpenWindowsSandboxFallbackPrompt` event by removing the `WindowsSandboxFallbackReason` enum and its associated `reason` parameter, streamlining event processing in `handle_app_event`. Additionally, it **updates OpenTelemetry metric names** related to Windows Sandbox prompts and introduces a new metric to track legacy setup preflight failures, ensuring more accurate and relevant usage data collection for the setup process.
This commit introduces a **new capability** to the **Windows sandbox integration** by allowing users to grant read access to previously inaccessible directories. It adds a new **slash command**, `/sandbox-add-read-dir`, to the **TUI** for manually specifying additional read roots. This addresses an edge case where the sandbox might fail to read certain paths, improving the overall robustness and user experience of the **sandbox environment**. The core library now includes new modules and functions like `grant_read_root_non_elevated` and `run_setup_refresh_with_extra_read_roots` to manage these permissions, enabling users to resolve sandbox access issues directly.
This commit significantly **refactors** and **enhances the user experience** for the **Windows Sandbox** feature, centralizing its configuration and streamlining the onboarding process. It introduces a new `windows.sandbox` configuration key, replacing legacy feature flags, and simplifies the NUX by moving it after the trust directory screen, removing the "read-only" option, and enforcing a "trust or quit" decision for untrusted directories. This change impacts the **core configuration system**, the **TUI onboarding flow**, and the **chat widget**, providing a clearer and more direct path for users to enable and configure the Windows Sandbox. The update also includes **maintenance** to handle legacy sandbox configurations and renames the `/setup-elevated-sandbox` command to `/setup-default-sandbox`.
This commit introduces a **new capability** to include sandbox environment information, such as "seatbelt" or "elevated" modes, directly within the **turn metadata header**. A new `sandbox_tags` module was added to `codex-rs/core` to centralize the logic for determining the appropriate sandbox tag, which is then integrated into the `build_turn_metadata_header` function and `Session::new`. This enhancement to the **telemetry system** provides crucial data for understanding user retention and usage patterns, particularly for users operating within various sandboxed environments. The change also involved **refactoring** existing sandbox tag logic from `codex-rs/core/src/tools/registry.rs` to utilize the new dedicated module, ensuring consistency and maintainability.
This commit introduces a **new capability** to enhance **observability** by adding **sandbox policy and name details** to `codex.tool.call` metrics. It modifies the **core tool execution registry** (`codex-rs/core/src/tools/registry.rs`) to capture this information during `handle_tool_call` and integrates it into the **OpenTelemetry tracing and metrics system** via `otel_manager.rs`. This allows for granular tracking of tool call outcomes, providing crucial **visibility into the comparative success rates of various sandbox implementations**, especially for Windows, to inform future performance and reliability improvements. The change also includes a new `as_metric_tag` method for `SandboxType` in `exec.rs` and updates a test case in the OpenTelemetry suite.