## Description
Add Codex as a supported local child-agent harness in the Warp client.
This updates local harness normalization and launch command
construction, and wires the CLI parsing and test coverage needed for
local child launches.
This is the client-side counterpart to
https://github.com/warpdotdev/warp-server/pull/10880.
## Linked Issue
https://linear.app/warpdotdev/issue/QUALITY-578/codex-support-for-orchestration
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [ ] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Testing
- `cargo +1.92.0 fmt --all`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 clippy --workspace
--exclude warp_completer --all-targets --tests -- -D warnings`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 clippy -p warp_completer
--all-targets --tests -- -D warnings`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 test -p warp_cli`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 test -p warp
local_child_task_config_records_supported_third_party_harnesses`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 test -p warp
execute_returns_error_when_local_harness_child_requires_orchestration_v2`
- `MACOSX_DEPLOYMENT_TARGET=10.14 cargo +1.92.0 test -p warp
execute_rejects_invalid_local_harness_names_before_pane_creation`
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Artifacts
- Conversation:
https://app.warp.dev/conversation/e4346560-106f-4bfc-a931-b705a9906799
- Plan: https://app.warp.dev/drive/notebook/BiU3vIJVoZ4jALRYFtNzdz
CHANGELOG-OZ: Add Codex as a supported harness for local child agents.
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
This PR introduces a new `HarnessAvailabilityModel`, following
server-side changes to expose the list of available harnesses for use
with Oz in the `availableHarnesses` section of the `User` GraphQL query.
We model this new model (ha) after the existing models (ha) model, which
stores the list of available LLMs (`LLMPreferences`) that we get from
the server.
We also update the cloud mode UI, management view filter, and CLI so
that we check this model to determine the list of harnesses to display
(rather than hardcoding them), as well as to show enabled/disabled state
when triggering something from cloud mode.
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
Example of disabled state for harnesses in cloud mode:
<img width="878" height="419" alt="image"
src="https://github.com/user-attachments/assets/a2b62e18-2a65-42aa-8b5b-c45b58d22855"
/>
No harnesses available state:
https://www.loom.com/share/65d9ed8f52be4a5ba4b1e320fdddff0b
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
-->
Tested locally, ensuring that:
- Disabled harnesses show up correctly
- Non-feature-flag-enabled harnesses don't show up
- Different UI surfaces all reflect the list from the server
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
Fixes orchestration v2 parent/child agent wake-up and messaging behavior
for remote child agents.
This PR updates the client-side orchestration flow so that incoming
parent-agent messages wake remote child agents through the server run
follow-up path instead of trying to treat them like local dormant Claude
harnesses. Previously, a remote child could receive the parent’s
message, but it would not be restarted correctly in a harness and could
fail or hang when trying to send a message back to the parent.
Main changes:
• Adds a remote-child wake path in the blocklist AI controller:
◦ detects remote child conversations with pending parent-agent message
events
◦ submits a run follow-up to agent/runs/{run_id}/followups
◦ removes delivered pending message events after successful follow-up
submission
◦ retries/logs failures instead of silently hanging
• Keeps local dormant Claude wake behavior separate from remote child
wake behavior.
• Restores remote hidden child panes as cloud/ambient agent panes
instead of local terminal-backed child panes.
• Ensures restored remote child panes enter the existing ambient session
in AgentRunning state.
• Persists and restores remote-child conversation metadata so the client
can distinguish local children from remote children across reloads.
• Improves orchestration v2 message sending:
◦ uses task-scoped server APIs when available
◦ adds bounded timeouts and error logging for send failures
◦ surfaces failures instead of leaving action execution indefinitely
pending
• Adds regression coverage for:
◦ remote child conversation restoration
◦ remote child pane/session state
◦ task-scoped ambient agent messaging
◦ orchestration v2 message/error behavior
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
If you're not sure whether you should add a test, check our testing
policy:
https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09
-->
## Server API dependencies
<!-- You may remove this section if your PR does not have any server
dependencies. -->
- [ ] Is this change necessary to make the client compatible with a
desired [server API breaking
change](https://www.notion.so/warpdev/How-to-safely-introduce-server-API-breaking-changes-0aa805ff5d5d41fd8834f3c95caba0b4?pvs=4#d55ecf8aea3449949d3c33b0e67f6800)?
- [ ] Does this change rely on a [new server
API](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#04da1e6a493542d68b3e998c7d339640)?
- [ ] If so, is the use of this API restricted to client channels that
rely on the staging server (e.g. WarpDev)?
- [ ] Is this change enabling the use of a server API on client channels
that rely on the production server (e.g. WarpStable)?
- [ ] If so, has the new server API been stable on production for at
least one server release cycle? See
[here](https://www.notion.so/warpdev/How-to-add-a-new-full-stack-feature-8412cede405a4ec194b32bdd4b951035?pvs=4#73b202f939834b97ab1fbdf7fc82cd53)
for more details.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
<!--
The entries below will be used when constructing a soft-copy of the
stable release changelog. Leave blank or remove the lines if no entry in
the stable changelog is needed. Entries should be on the same line,
without the `{{` `}}` brackets. You can use multiple lines, even of the
same type. The valid suffixes are:
* NEW-FEATURE: for new, relatively sizable features. Features listed
here will likely have docs / social media posts / marketing launches
associated with them, so use sparingly.
* IMPROVEMENT: for new functionality of existing features.
* BUG-FIX: for fixes related to known bugs or regressions.
* IMAGE: the image specified by the URL (hosted on GCP) will be added to
Dev & Preview releases. For Stable releases, see the pinned doc in the
#release Slack channel.
* OZ: Oz-related updates. Use `CHANGELOG-OZ`. At most 4 Oz updates are
shown in-app per release.
-->
CHANGELOG-NEW-FEATURE: {{text goes here...}}
CHANGELOG-IMPROVEMENT: {{text goes here...}}
CHANGELOG-BUG-FIX: {{text goes here...}}
CHANGELOG-BUG-FIX: {{more text goes here...}}
CHANGELOG-IMAGE: {{GCP-hosted URL goes here...}}
CHANGELOG-OZ: {{text goes here...}}
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
Given the fact that we're planning on accommodating multiple variants of
cloud agents, we need to change the agent icons in the conversation
list, notifications, pane header, and vertical tabs to support different
harnesses. Peter drew up some mocks for this, and we'll use the new icon
+ status variants across all of these surfaces.
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
If you're not sure whether you should add a test, check our testing
policy:
https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09
-->
demo: https://www.loom.com/share/066e5842bf0541fa808925100cc6529e
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Most `target_os = "linux"` cfg sites in this tree gate code that already
works fine on FreeBSD. wayland-client, cctk, fontconfig, x11rb,
native-dialog, notify-rust, and the WindowingSystem enum all compile and
run there using the existing Linux branches. Widening those cfg guards
from `target_os = "linux"` to `any(target_os = "linux", target_os =
"freebsd")` is enough to get a working build.
The change is mechanical: 79 files across `app/` and `crates/`, all of
them just adjusting the cfg.
One Linux-only carveout: `InputFlags::IUTF8` in
`app/src/terminal/local_tty/unix.rs`. nix does not expose that termios
input flag on FreeBSD, and the PTY works without it.
Linux, macOS, and Windows are unaffected by construction: every widened
cfg already evaluated true on Linux and continues to; neither macOS nor
Windows ever matched these guards.
Tested by building `warp-oss` on FreeBSD 16-CURRENT amd64 with rust 1.92
and launching it under wayland (niri).
<img width="2560" height="1440" alt="image"
src="https://github.com/user-attachments/assets/085f3b8c-621c-4fbb-adc8-69daebc03d3a"
/>
## Description
This passes the app version through to `clap`, so that the `--version`
flag is supported.
## Testing
Ran locally with `--version` and `-V`, using a fake Git release tag.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-BUG-FIX: Added `--version` flag support in the Oz CLI
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
This PR sets up the initial plumbing for supporting the Codex CLI with
multi-harness. It follows the existing pattern for Claude Code and
Gemini, implementing the `ThirdPartyHarness` trait for codex.
Notable decisions:
- We run the CLI with `--dangerously-bypass-approvals-and-sandbox`
([docs](https://developers.openai.com/codex/agent-approvals-security#run-without-approval-prompts))
- We provide the system prompt by writing to `AGENTS.override.md`
([docs](https://developers.openai.com/codex/guides/agents-md))—codex
reads this first and recommends it for temporary instructions. It
doesn't really matter yet which we use since these are running in a
cloud agent context where we control the FS.
- Codex, like Gemini, unfortunately doesn't support file input or
redirecting stdin. We reuse the `$(cat prompt_file)` approach here for
now.
## Testing
<!--
How did you test this change? What automated tests did you add? If you
didn't add any new tests, what's your justification for not adding any?
If you're not sure whether you should add a test, check our testing
policy:
https://www.notion.so/warpdev/How-We-Code-at-Warp-257fe43d556e4b3c8dfd42f70004cc72#1f97825450504baa9c5fd87a737daa09
-->
Tested E2E in downstream PR,
https://github.com/warpdotdev/warp/pull/9376
Also confirmed that it picks up the system prompt instructions:
<img width="1353" height="912" alt="image"
src="https://github.com/user-attachments/assets/6665db5a-fbf3-427f-b95d-2e5c627f3865"
/>
## Server API dependencies
<!-- You may remove this section if your PR does not have any server
dependencies. -->
Relies on the support for Codex added to the server in
https://github.com/warpdotdev/warp-server/pull/10740
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
---------
Co-authored-by: Oz <oz-agent@warp.dev>
