## Why
Selected capability roots belong to the executor filesystem, not the
app-server host. Converting their path strings into the host's native
`Path` breaks whenever the two machines use different path conventions,
such as a Windows executor behind a Unix app-server.
This PR establishes `PathUri` as the selected-plugin boundary so the
executor remains authoritative for its paths.
## What changed
- Require `selectedCapabilityRoots[].location.path` to be a canonical
`file:` URI and deserialize it directly as `PathUri`; native path
strings are rejected.
- Update the app-server schema, generated TypeScript, examples, and
request coverage for the URI contract.
- Keep selected roots, resolved plugin locations, manifest paths, and
manifest resources as `PathUri`.
- Inspect and read plugin roots and manifests only through the selected
environment's `ExecutorFileSystem`.
- Parse executor manifests with the shared URI-native parser from #29620
instead of projecting them onto the host filesystem.
- Enforce resource containment lexically and preserve the root URI's
POSIX or Windows path convention.
- Cover foreign Windows plugin roots and URI-native manifest resources.
```text
thread/start
selectedCapabilityRoots[].location.path = "file:///C:/plugins/demo"
| PathUri
v
ExecutorFileSystem
|
+--> plugin.json
+--> manifest resources
```
This PR stops at the shared selected-plugin representation. The next two
PRs remove the remaining host-path projections in the skill and MCP
consumers.
## Stack
1. #29614 — add lexical `PathUri` containment.
2. #29620 — share URI-native manifest path resolution.
3. **This PR** — keep selected plugin roots and resources URI-native.
4. #29626 — load executor skills without host path conversion.
5. #29628 — resolve executor MCP working directories without host path
conversion.
## Why
PR #29494 made context-window IDs visible to the model by wrapping the
token-budget window payload in `<context_window>`, but rollout JSONL
consumers still could not see the initial window identity by tailing the
session file. Compacted rollout items carry window IDs only after
compaction has happened, so a session with no compaction had no durable
JSONL record for window 0.
This change gives tailing consumers a stable initial-window record at
session creation time.
## What Changed
- Added `session_meta.context_window.window_id` for the initial
context-window identity.
- `CreateThreadParams` now requires `initial_window_id: String`, so
thread-store callers cannot accidentally create new threads without
window-0 metadata.
- Live thread creation derives the persisted initial window ID from the
same `AutoCompactWindowIds` used to initialize `SessionState`, keeping
runtime state and JSONL metadata aligned.
- Rollout reconstruction uses `session_meta.context_window.window_id` as
the initial-window fallback and derives `window_number = 0`,
`first_window_id = window_id`, and `previous_window_id = None`
internally.
- Fork reconstruction intentionally uses the same rollout reconstruction
path; consumers that need to distinguish copied initial-window metadata
can use the rollout `thread_id`.
- Legacy compactions without `window_number` still use compaction-count
fallback accounting instead of being reset to window 0 by the
initial-window fallback.
- Compacted rollout metadata still takes precedence once compaction
records exist, preserving the richer chain fields there.
## JSONL Shape
Real rollout JSONL is one object per line. This example is expanded for
readability, but shows the new initial `session_meta.context_window`
record followed by the existing compacted rollout item shape that also
carries window IDs:
```jsonl
{
"timestamp": "2026-06-22T12:00:00.000Z",
"type": "session_meta",
"payload": {
"session_id": "<THREAD_ID>",
"id": "<THREAD_ID>",
"timestamp": "2026-06-22T12:00:00.000Z",
"cwd": "/repo",
"originator": "codex",
"cli_version": "0.0.0",
"source": "cli",
"model_provider": "<MODEL_PROVIDER>",
"context_window": {
"window_id": "<INITIAL_WINDOW_ID>"
}
}
}
...
{
"timestamp": "2026-06-22T12:34:56.000Z",
"type": "compacted",
"payload": {
"message": "<COMPACTION_SUMMARY>",
"replacement_history": [
"..."
],
"window_number": 1,
"first_window_id": "<INITIAL_WINDOW_ID>",
"previous_window_id": "<INITIAL_WINDOW_ID>",
"window_id": "<NEXT_WINDOW_ID>"
}
}
```
The nested `context_window` object is intentional: it gives rollout
consumers a stable namespace for context-window metadata while only
writing the non-derivable initial `window_id`. For the initial window,
`window_number`, `first_window_id`, and `previous_window_id` are derived
internally instead of being written to the rollout.
## Verification
- `just test -p codex-protocol`
- `just test -p codex-rollout
recorder_materializes_on_flush_with_pending_items`
- `just test -p codex-core reconstruct_history`
- `just test -p codex-core
record_initial_history_reconstructs_forked_transcript`
- `just test -p codex-thread-store`
- `just test -p codex-state`
- `just test -p codex-app-server
thread_read_returns_summary_without_turns`
- `just test -p codex-rollout persistence_metrics`
## Why
I'd originally added `PathUri` legacy path deserialization thinking we'd
want it for having `PathUri` in public app-server APIs. Since then we've
added `LegacyAppPathString` to handle the messy conversions that we need
for backcompat. It's confusing for `PathUri` to support deserializing
legacy paths when we don't yet want to actually expose app-server
callers or rollout storage to the new URI format.
Stacked on top of #29472 to avoid breaking compatibility in case those
types ended up stored somewhere for someone.
## What changed
- Parse deserialized `PathUri` values exclusively as valid `file:` URIs.
- Replace legacy acceptance coverage with rejection coverage for
top-level filesystem paths and sandbox working directories.
- Serialize CWDs in hand-built exec-server process requests as `PathUri`
values.
## Why
Use a clearer name for what happens when this helper sets up a test
environment.
## What
- Rename the builder and its harness wrapper to use `auto_env` instead
of `remote_env` because the helper will set up a local environment if
configured by the build system.
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Rollout reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Forks intentionally use the same reconstruction path; consumers that need to distinguish copied initial-window metadata can use thread_id. Legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core reconstruct_history
- just test -p codex-core record_initial_history_reconstructs_forked_transcript
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
- just fix -p codex-core
## Why
Core tests should branch on the executor's operating system, not on
runner details such as Docker or Wine. This keeps platform behavior
stable as new test backends are added and reserves Wine-specific skips
for actual runner debt.
## What
- Add `TestTargetOs` and target/host-aware skip helpers while keeping
`TestEnvironment` internal.
- Replace topology enum access with remote predicates and a narrow
Docker accessor.
- Migrate OS-semantic Wine skips, preserve runner-specific gaps, and
document the skip taxonomy.
## Validation
- `just test -p core_test_support`
- `just test -p codex-core
remote_test_env_can_connect_and_use_filesystem`
- `bazel test //codex-rs/core:core-all-wine-exec-test
--test_output=errors` reached test execution; unrelated existing
view-image, path, and timing failures remain.
- `just test -p codex-core` and `just test` reached broad test
execution; this checkout has unrelated helper, sandbox, and timing
failures.
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Rollout reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Forks intentionally use the same reconstruction path; consumers that need to distinguish copied initial-window metadata can use thread_id. Legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core reconstruct_history
- just test -p codex-core record_initial_history_reconstructs_forked_transcript
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
- just fix -p codex-core
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Rollout reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Forks intentionally use the same reconstruction path; consumers that need to distinguish copied initial-window metadata can use thread_id. Legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core reconstruct_history
- just test -p codex-core record_initial_history_reconstructs_forked_transcript
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
- just fix -p codex-core
Mechanical rename of CodeModeService => InProcessCodeModeSession
This already implements a CodeModeSession as its prime interface to
Core. The name was vestigial _and_ confusing af when embedded inside
core::tools::code_mode::CodeModeService
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Rollout reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Forks intentionally use the same reconstruction path; consumers that need to distinguish copied initial-window metadata can use thread_id. Legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core reconstruct_history
- just test -p codex-core record_initial_history_reconstructs_forked_transcript
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
- just fix -p codex-core
## Description
Rename the experimental app-server item pagination API from
`thread/turns/items/list` to `thread/items/list` and make `turnId`
optional. Clients can now page persisted items across a thread, or still
filter to one turn when needed.
## What changed
- Rename the request/response protocol types and JSON-RPC method to
`ThreadItemsList*` / `thread/items/list`.
- Pass optional `turnId` through to `ThreadStore::list_items`.
- Update app-server docs and focused protocol/app-server tests.
## Validation
- `just test -p codex-app-server-protocol thread_items_list_round_trips`
- `just test -p codex-app-server thread_items_list_returns_unsupported`
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
## Summary
- add the exec-server working directory to `environment/info` as an
optional `PathUri`
- populate it from the executor process's current directory
- preserve compatibility with older responses that omit `cwd`
## Why
Remote clients currently have no executor-native default working
directory. This forces callers such as app-server-backend to assume
`/workspace`, which fails for laptop environments. Reporting the cwd
alongside the detected shell lets clients use the path convention and
location of the actual executor.
## Impact
This is backward-compatible: the new response field is optional, and
clients can continue handling responses from older exec servers. A
follow-up app-server-backend change will consume the value for cwd-less
`command/exec` requests.
## Validation
- `just test -p codex-exec-server` (275 passed, 2 skipped)
## Why
Plugin manifests use the same schema whether the package lives on the
host or in an executor. Only the path representation differs: host
callers need native `Path` inputs and `AbsolutePathBuf` outputs, while
executor callers need `PathUri` throughout.
Maintaining separate parsing or resolver implementations would duplicate
the manifest rules and allow them to drift. This PR instead makes
URI-native resolution the single parsing path and keeps host conversion
at the boundary.
## What changed
- Make `parse_plugin_manifest_uri` the shared manifest parser and
resolve every path-bearing field as `PathUri`.
- Keep the existing host entrypoint as a thin adapter: convert its
native root and manifest path to `PathUri`, run the shared parser, then
map resources back to `AbsolutePathBuf`.
- Expose `PluginManifest::try_map_resources` so callers can convert the
generic resource type without duplicating manifest construction.
- Resolve relative manifest paths using the root URI's convention:
backslashes are separators for Windows roots and ordinary filename
characters for POSIX roots.
- Apply lexical containment after URI resolution, rejecting absolute
paths and parent traversal outside the plugin root.
- Make encoded backslashes fail containment only for Windows URIs;
encoded `/` remains unsafe for every convention.
- Use a host-native synthetic root for marketplace fallback manifests so
the host adapter also works on Windows.
```text
host Path --------> PathUri --\
+--> one manifest parser --> PluginManifest<PathUri>
executor PathUri -------------/
host result: PluginManifest<PathUri> --> PluginManifest<AbsolutePathBuf>
```
Existing host manifest behavior is preserved; #28918 is the first
executor consumer.
## Verification
- `just test -p codex-utils-path-uri`
- `just test -p codex-plugin`
- `just test -p codex-core-plugins`
## Stack
1. #29614 — add lexical `PathUri` containment.
2. **This PR** — share URI-native manifest path resolution.
3. #28918 — keep selected plugin roots and resources URI-native.
4. #29626 — load executor skills without host path conversion.
5. #29628 — resolve executor MCP working directories without host path
conversion.
## Why
auto review reviews Codex App tool calls using connector metadata such
as the app ID, name, and description. That metadata does not identify
the account behind the OAuth connection.
For Google Drive, this means auto review cannot distinguish a Drive
connection authenticated as `user@email.com` from a personal Drive
account. Uploading work data can therefore look like a transfer to a
personal destination even though the connector service already knows the
authenticated account email.
## What changed
- Read `_meta._codex_apps.connected_account_email` while resolving
approval metadata for built-in Codex App tools.
- Include the connected account email in the structured MCP tool action
sent to auto review.
- Trim empty values and omit the field when the connector link has no
account email.
- Update existing auto review request constructors and add coverage for
request construction and JSON serialization.
## Security
Only metadata from the trusted built-in `codex_apps` MCP server is
accepted. Custom MCP servers cannot inject a connected account email
into auto review reviews; the new regression test verifies that spoofed
metadata is ignored.
The email is used only in auto review's private review request. This
change does not add it to model-visible tool descriptions, app-server
approval events, or auto review assessment/review analytics.
[Codex Thread
019edc37-5345-7272-92c9-bf5494cf3819](https://codex-thread-link.openai.chatgpt-team.site/thread/019edc37-5345-7272-92c9-bf5494cf3819)
## Summary
- count MCP `CallToolResult.isError` responses as failed calls instead
of successful transport-level calls
- add `codex.mcp.call.error` with bounded `error_type` and trusted
plugin-service `error_code` dimensions
- record the same error classification on MCP tool-call spans while
keeping untrusted server error text out of metric labels
## Scope
- no changes to MCP routing, retries, tool behavior, configuration, or
public APIs
- request failures remain grouped as `mcp_request`; separating
connection, timeout, protocol, and JSON-RPC failures requires preserving
typed errors through the existing flattened error boundary
## Testing
- `just test -p codex-core 'mcp_tool_call::tests::'` (75 passed)
- `just fix -p codex-core`
- `just fmt`
- `just test -p codex-core` (2,676 passed; 80 unrelated environment
failures from missing test binaries, sandbox signals, and read-only
paths)
## Why
With deferred executors, an environment can become ready between two
sampling requests in the same turn. The model-visible environment
update, advertised tools, and eventual tool execution must all describe
the same request-time view.
Otherwise, a request built while only environment B is ready can
advertise a tool without an `environment_id`; if higher-priority
environment A becomes ready before execution, that call could silently
run in A instead.
This PR is stacked on #29527.
## Design
`run_turn` captures one `Arc<StepContext>` at each sampling-request
boundary. That step owns the request's `TurnContext` and environment
snapshot.
- World-state environment updates and tool planning borrow that same
step.
- `ToolCallRuntime` retains the `Arc` while asynchronous tool calls
execute.
- `ToolInvocation` carries the step to handlers; its temporary `turn`
compatibility field is derived from the same object.
- `ToolRouter` does not retain `StepContext`; it only uses it while
constructing the request's tool set.
- With `DeferredExecutor` disabled, step capture keeps using the
environments frozen at turn start.
Simply: every sampling request gets one consistent picture of its
environments, from what the model sees through where its tool calls run.
## What changed
- Build environment-dependent tool specs from the current request's
`StepContext`.
- Use that same step for unified exec, legacy shell, `apply_patch`,
`view_image`, and `request_permissions` execution.
- Hide environment-backed tools, including `request_permissions`, while
no environment is attached.
- Resolve legacy shell paths and metadata from the selected step
environment instead of the stale turn-start environment.
- Capture explicit steps at non-turn-loop boundaries such as compaction,
prompt debug, and startup prewarm.
- Reconcile prompt-debug history from the same step used to build its
tools.
## Follow-up
- Bind yielded code-mode cells to the tool runtime that created them, so
nested calls made after yielding continue to use the originating
request's `StepContext`.
## Test plan
- `just test -p codex-core
deferred_executor_updates_context_and_tools_after_startup`
- `just test -p codex-core
environment_count_controls_environment_backed_tools`
- `just test -p codex-core
build_prompt_input_includes_context_and_user_message`
## Summary
- replace the removed `AskForApproval::OnFailure` variant in the MCP
shutdown test with `OnRequest`
## Why
`OnFailure` was removed from `AskForApproval`, but this test fixture
still referenced it, causing Rust and Clippy compilation failures.
## Validation
- `just test -p codex-mcp shutdown_continues_after_caller_is_aborted`
- `just fmt`
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
## Summary
- replace the stale `AskForApproval::OnFailure` reference in the MCP
connection manager test with `AskForApproval::OnRequest`
- restore `codex-mcp` test compilation after `OnFailure` was removed in
#28418
## Root cause
The test was added on main after the approval-policy removal branch had
already updated the other references, so the newly added call site was
missed when #28418 merged.
## Validation
- `just test -p codex-mcp` (90 passed)
- `just fmt`
## Why
view_image needs to support foreign OS remote executors.
## What
- resolve image paths against the selected environment as `PathUri` and
read them through that environment's filesystem
- keep app-server's public path field wire-compatible as
`LegacyAppPathString`, with purpose-specific UI rendering
- cover relative and absolute target-native paths in the core
integration test and run the full `view_image` suite under wine-exec
without skips
Michael Bolin