When a repository update arrives, the stream handler removes rules from
the path_to_rules HashMap and re-inserts them asynchronously after
processing. If a second update arrives during this async gap (e.g. from
a git checkout or atomic file save), the remove returns None and the
update is silently dropped. If the first update was a deletion and the
dropped second update was the corresponding addition, the rules are
permanently lost until client restart.
Fix: clone the rules instead of removing them so they remain available
in the HashMap during async processing, and serialize update processing
per path by tracking in-flight tasks and queuing updates that arrive
during the async gap. When a task completes, queued updates are drained
and processed sequentially against the latest state, preventing both the
permanent-loss bug and stale-snapshot overwrites.
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! -->
Fixes https://warpdev.slack.com/archives/C08KTPNQN65/p1777573039998779.
The issue was that there were two views subscribing the up arrow event
and both would handle it. Both the normal history menu and the cloud
mode-only history menu would emit events in rapid succession. We now
make sure that only one of the views ever fires off events, since only
one history menu should be active at a time.
## 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?
-->
Before, hitting the up arrow in the agent conversation view would cause
the buggy behavior Roland described: the first query would get inserted
into the buffer and the history menu would appear to never open. Now, it
WAI.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
The release bundling workflow runs `prepare_bundled_resources` after the
main `cargo build`, and that script in turn invokes `cargo run --bin
generate_settings_schema`. Until now we passed neither `--features` nor
`--target` to this run, so cargo's resolver-v2 saw a different
per-package feature unification than the main build and recompiled every
dependency whose enabled features differed (`rust-embed` with
`debug-embed`, `warp_core`'s `release_bundle`, sentry, jemalloc, etc.).
This added significant time to release builds and pulled in extra system
dependencies (e.g. protoc) for jobs that should otherwise just be
packaging the prebuilt binary.
There was a secondary correctness issue: the schema generator iterates
settings registered via `inventory::submit!`, and `#[cfg(feature =
\"...\")]`-gated settings were silently omitted from the schema in any
context whose feature set didn't match the main binary.
The fix threads the build's feature set (and target, where applicable)
through to the schema-generator invocation, and makes package selection
explicit with `-p warp`. With matching features and target, cargo reuses
the existing compilation artifacts; with the same feature set, the
generated schema is also faithful to what the bundled binary actually
exposes.
## Testing
Verified `bash -n` syntax for the modified bash scripts and parsed the
modified PowerShell files via `pwsh`. Bundling, schema generation, and
CI behavior will be exercised by this PR's release builds.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
[Conversation](https://staging.warp.dev/conversation/1bd5574f-df28-4c2e-867d-40d71ed7e827)
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
We are looking at making Linux builds more efficient, but for now bump
the linux build timeouts.
## Linked Issue
<!--
Link the GitHub issue this PR addresses. Before opening this PR, please
confirm:
-->
- [ ] 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).
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
## 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?
-->
## 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...}}
-->
## Description
Fix alignment and width of the git operations dropdown menu in the code
review header (behind the `GitOperationsInCodeReview` feature flag).
**What:** Two fixes to the git operations button/menu in
`render_git_operations_button`:
1. The dropdown menu was too wide (defaulting to 186px). Set it to 140px
via `.with_width(140.)` on the `Menu` view at construction time.
(aligned with the [Figma mocks
here](https://www.figma.com/design/T2CtyXgIdjtrLfC03K1n1H/Code-review-2.0?node-id=6138-21140&p=f&m=dev))
2. The dropdown was misaligned with the button/chevron. The
`margin_right(4.)` was previously applied inside the `Stack`, inflating
the Stack's layout box by 4px and causing the `BottomRight`/`TopRight`
overlay anchor to overshoot. Moved the margin to a wrapping `Container`
outside the Stack so the Stack's right edge is flush with the chevron's
right edge.
**Why:** The menu appeared too wide and visually misaligned with the
button it belongs to.
**How:** In `header_revamp.rs`, removed the intermediate `Container`
wrapping the button row inside the `Stack` and instead wrap the finished
`Stack` in a `Container::new(...).with_margin_right(4.)`. In
`code_review_view.rs`, chain `.with_width(120.)` onto the `Menu::new()`
builder so the menu's internal `submenu_width` is set correctly.
Fixes
[APP-4180](https://linear.app/warpdotdev/issue/APP-4180/this-dropdown-menu-is-not-properly-right-aligned-also-i-think-it)
<img width="380" height="183" alt="image"
src="https://github.com/user-attachments/assets/52d7de8c-cc5e-4b8d-b60e-76b99862394d"
/>
## Description
`is_file_openable_in_warp` returns `Some(Text)` for any non-binary file,
which shadowed the existing executor branch in `open_file` when handling
a `file://` URL — so executable shell scripts were opened in the editor
instead of being run. The URI handler now classifies the action up front
via a new pure helper `classify_open_file_action`, and routes executable
shell scripts to the executor path that the rest of the agent flow
already uses.
Detection rules for "runnable shell script":
- **Unix:** user-execute bit set AND (extension in `{sh, bash, zsh,
fish, ksh}` OR file starts with a `#!` shebang).
- **Windows:** extension in `{ps1, bat, cmd}` (no x-bit concept).
Non-executable shell scripts still open in the editor — the routing is
gated on the user-execute bit on Unix, so this only changes behavior for
files the user marked executable.
Fixes#9005.
## Testing
Unit tests added at both layers:
- **`is_runnable_shell_script`** — 7 tests in
`app/src/util/openable_file_type.rs`: executable `.sh`, non-executable
`.sh`, alternate executable extensions (`.bash`, `.zsh`, `.fish`,
`.ksh`), shebang-with-no-extension (with and without x-bit), plain-text
rejection, symlink to executable.
- **`classify_open_file_action`** — 6 tests in
`app/src/uri/uri_test.rs`: executable `.sh` → execute, non-executable
`.sh` → editor, executable `.bash`/`.zsh`/`.fish` → execute, markdown →
notebook, Rust source → editor, directory → session.
`./script/presubmit` is clean (`cargo fmt`, `cargo clippy --workspace
--all-targets --tests -- -D warnings`, `clang-format`, `wgslfmt`, `cargo
nextest`). The 5 `shell_integration_tests::*ssh*` failures observed
locally are unrelated to this change — they require a Docker SSH
container — and are skipped on fork PRs per #9304.
## Agent Mode
- [ ] Warp Agent Mode — This PR was created via Warp's AI Agent Mode
CHANGELOG-BUG-FIX: Executable shell scripts opened from a \`file://\`
URL now run in the terminal instead of opening in the editor.
## Description
When Warp starts a shared agent session, we now link that shared session
to the associated Oz run on the server. This enables the Oz run record
to carry the replay session ID, so the session can be surfaced alongside
the run.
**How it works:**
- In `TerminalManager`, when a shared session is created successfully,
the Oz task ID is resolved from the active conversation's `task_id` (set
when the first `StreamInit` response arrives). If found,
`update_agent_task` is called to associate the shared session ID with
the Oz run.
- In the Oz webapp, the "View session" button links to the conversation,
which then redirects to the session if there is one that is active.
**Note on CLI agent runs (`warp agent run`):**
In the CLI agent driver, the shared session is established *before* the
first AI prompt is sent (`wait_for_session_shared()` completes at step 3
of `run_internal`, while the prompt is dispatched at step 5). This means
`active_conversation()` returns `None` at link time and the
session-to-task link is silently skipped for this path. A follow-up will
address linking for CLI agent runs — possible approaches include
deferring the link call until after the first prompt is sent, or
re-introducing a read from `BlocklistAIController.ambient_agent_task_id`
(which the driver sets before sharing begins).
Implements
[REMOTE-1326](https://linear.app/warpdotdev/issue/REMOTE-1326/link-shared-sessions-to-local-interactive-oz-runs).
## Testing
Tested manually by running an in-app Oz agent session, sharing the
terminal, and verifying the resulting Oz task record on the server has
the shared session ID populated.
No automated tests added: the linking path requires a live server
round-trip (shared session creation + `update_agent_task`) and the
happy-path success is silent by design; only failures are logged.
## Server API dependencies
- [ ] Is this change necessary to make the client compatible with a
desired server API breaking change?
- [x] Does this change rely on a new server API?
- [ ] Is this change enabling the use of a server API on client channels
that rely on the production server?
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
We currently have a bug with session restoration where maximized windows
won't restore into the maximized state. This is due to the "vertical
adjustment" code which tries to make sure the title bar is on screen (it
moves the window downward if that isn't the case). Without getting too
much into the details, on Windows when windows are maximized, winit
reports the physical size of the window _as if_ it had the native window
decorations, even when it doesn't. It treats the native title bar as
being off the screen and represents that with a negative origin (above
the screen). This triggers `fn maybe_adjust_window_vertically` to return
a value which triggers the caller to try to move the window which makes
Windows un-maximize the window. This simple guard fixes the problem
## Testing
1. Run Warp on Windows
2. Make sure session restoration is enabled
3. Maximize the window
4. quit warp
5. Start warp again
6. The window should be maximized but it isn't
On this branch, that bug no longer occurs.
## Description
Update the default fallback owner for the root `/` pattern in
`.github/STAKEHOLDERS` from the list of FA leads to the
`@warpdotdev/oss-maintainers` team.
## Linked Issue
N/A — small ownership update.
- [ ] 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).
## Screenshots / Videos
N/A — no UI changes.
## Testing
No code changes; this only updates the STAKEHOLDERS file used by the
triage workflow.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
_Conversation:
https://staging.warp.dev/conversation/5d3add1a-47d9-4eb8-9400-a84b51e9f920_
_Run:
https://oz.staging.warp.dev/runs/019ddf7c-4acd-7a1d-8470-5f40af986b2b_
_This PR was generated with [Oz](https://warp.dev/oz)._
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Refs #9522.
After #9513 bundled `LICENSE-ALACRITTY` and added attribution headers to
the original tranche of derivative files, [@chrisduerr (Alacritty
maintainer) followed
up](https://github.com/warpdotdev/warp/issues/9522#issuecomment-4350152049)
and named two specific files that were still missing attribution:
> - This is an almost verbatim copy of VTE's ansi.rs module:
> `crates/warp_terminal/src/model/ansi/control_sequence_parameters.rs`
> - This function (and several others) are also verbatim copies:
> `app/src/terminal/grid_renderer/cell_type.rs:L160`
This PR adds the same two-line "adapted from … under the Apache license"
comment header that #9513 introduced, pointing to the same bundled
`crates/warp_terminal/src/model/LICENSE-ALACRITTY`:
| File | Attribution |
| ---- | ----------- |
| `crates/warp_terminal/src/model/ansi/control_sequence_parameters.rs` |
"adapted from the vte crate (an Alacritty project)" — file-wide |
| `app/src/terminal/grid_renderer/cell_type.rs` | "color-mapping helpers
(`compute_fg_rgb`, `compute_bg_rgb`, `get_override_color`) below are
adapted from the alacritty_terminal crate" — scoped because `Secret` /
`IsFocused` / `CellType` at the top of the file are Warp-specific |
Both files now point to the existing
`crates/warp_terminal/src/model/LICENSE-ALACRITTY` (Apache-2.0 — the
same license `vte` and `alacritty_terminal` both ship under). No
license-file changes are needed.
This is documentation/attribution only — no functional changes.
## Scope
This PR addresses the **two files explicitly cited** in #9522 by the
Alacritty maintainer. The cited comment also says "this function and
several others" — the "several others" likely includes the
immediately-adjacent `compute_bg_rgb` and `get_override_color` helpers
in the same `cell_type.rs` (they are similar verbatim ports), which is
why this PR's attribution covers all three of them. A broader audit of
files that *might* be derivative beyond what's explicitly cited is best
done by Warp's team or the Alacritty maintainers directly, since it
requires intimate knowledge of upstream history; happy to extend this PR
to cover any additional files that get flagged.
## Testing
Documentation/comments only. `cargo fmt -- --check` clean. No code paths
affected.
## Server API dependencies
- [ ] No server impact.
## Agent Mode
- [ ] Warp Agent Mode
## Changelog Entries for Stable
(None — internal/legal attribution metadata.)
## Description
Fixes#9534.
`script/linux/install_test_deps:32` registered Google Cloud SDK's apt
signing key via `apt-key`, which was removed from `apt` in 2.9.17
(2024-12) and is no longer present on Ubuntu 25.04+ and
Debian 13+. On those distros `script/linux/bootstrap` failed for any
contributor who didn't already have `gcloud` installed, with a confusing
`sudo: 'apt-key': command not found` / `curl: Failed writing body` pair.
Replaced the `apt-key` invocation with `gpg --dearmor`, which is the
documented replacement and works on every Debian-family release back to
Debian 9 / Ubuntu 16.04 — the same lower bound that the existing
`signed-by=/usr/share/keyrings/cloud.google.gpg` directive on the next
line already imposes. Also switched `curl -f` to `curl -fsSL`, the
standard quiet-but-fail-on-error flag set, and added `--yes` so a stale
keyring left from a partial previous bootstrap is overwritten cleanly.
```diff
- curl -f https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
+ curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor --yes -o /usr/share/keyrings/cloud.google.gpg
```
This is a strict superset of the previous behavior — it works everywhere
the old command worked and additionally on apt 3.0+ where `apt-key` is
gone.
## Testing
Manually ran the patched line on Ubuntu 25.10 (apt 3.1.6, no `apt-key`
binary): it produces `/usr/share/keyrings/cloud.google.gpg` and the
subsequent `apt-get update` / `apt-get install google-cloud-cli`
succeed. Re-ran a second time to confirm `--yes` overwrites the existing
keyring without prompting. No automated regression test added — this is
a one-line bootstrap script change whose failure mode is environmental
(absence of `apt-key` on the host) and CI runs on a distro where the
bug doesn't reproduce.
## Server API dependencies
No server API dependencies.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
CHANGELOG-BUG-FIX:
Co-Authored-By: Warp <agent@warp.dev>
## Summary
- Bumps `actions/setup-node` in
`.github/actions/prepare_environment/action.yml` from v3.9.1 (Nov 2023)
to v6.4.0 (Apr 2026).
- Motivation: the v3 line runs on a Node 16 action runtime, which GitHub
Actions has been deprecating. v4 → Node 20, v5/v6 → Node 24.
- The only input we pass is `node-version: 20.9.0`. None of the inputs
whose semantics changed across majors (`cache`, `always-auth`,
`registry-url`) are used here, so the upgrade is behaviorally inert for
our usage.
## Test plan
- [ ] CI passes on Linux, macOS, and Windows runners that exercise
`prepare_environment`.
- [ ] No new deprecation warnings related to `setup-node` in the action
logs.
## Description
Adds `libclang-dev` and `clang-format` to the Debian/Ubuntu package list
installed by `script/linux/install_build_deps` (run via
`script/linux/bootstrap`).
Without these, `script/presubmit` fails on a fresh Linux machine that
only ran `script/linux/bootstrap`:
- `clang-format` is invoked directly by the presubmit's C/C++/Obj-C
format check.
- `libclang-dev` pulls in `libclang-common-*-dev`, which provides
clang's resource-dir builtin headers that bindgen needs when nextest
builds `minimp4-sys` (pulled in via `warpui_core`'s `integration_tests`
feature).
Fixes#9526.
## Testing
Manually verified on a fresh Ubuntu setup that `script/linux/bootstrap`
followed by `script/presubmit` no longer fails on the clang-format check
or the bindgen build for `minimp4-sys`. No automated tests added — this
is a build-deps-only change to a shell script.
## Server API dependencies
N/A — no server API changes.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Fixes#9517
## Description
Meta+enter (among others) was sending the ESC plus the literal string
`enter` instead of anything reasonable! This has been bothering me for
ages and is because `meta_keystroke_to_escape_sequence` falls back to
sending the key name as literal ASCII bytes when the key isn't in
map_special_key_to_bytes.
Add the missing entries to map_special_key_to_bytes:
- enter/numpadenter → CR (\r)
- tab → HT (\t)
- escape → ESC (\x1b)
## Testing
Didn't add tests as I think they'd just be repeating the implementation.
## 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
CHANGELOG-BUG-FIX: Fixed Option+Enter, Option+Tab, and Option+Escape
sending literal key names instead of correct escape sequences
## Description
Fixes APP-4002
<img width="444" height="303" alt="Screenshot 2026-04-28 at 5 42 20 PM"
src="https://github.com/user-attachments/assets/1c45e5fa-1a20-4aa9-8666-c6d59b781fa5"
/>
This is a defensively coded UI in case something else leads to missing
file contexts.
<img width="469" height="113" alt="Screenshot 2026-04-28 at 5 40 44 PM"
src="https://github.com/user-attachments/assets/f2bd2c03-c529-49a2-8c6c-4d1efdc37544"
/>
When an LLM requests a `read_files` tool call with line ranges entirely
beyond EOF (e.g., lines 1891–2090 of a 1237-line file), the client
returns `ReadFilesResult::Success { files: [] }` — the file silently
vanishes from the result. This renders as an empty box with a green
checkmark in the blocklist UI.
**Root cause:** `TextFileAccumulator::flush_range` only emitted a
segment on final flush for whole-file reads (`final_flush &&
self.whole_file`). For ranged reads where no lines fall within the
requested range, the buffer stays empty and no segment is emitted. The
file ends up in neither `file_contexts` nor `missing_files`.
**Fix:**
1. **Primary:** Change `flush_range` to always emit a segment on final
flush (`!self.buf.is_empty() || final_flush`), so every requested range
produces a `TextFileSegment` even when entirely past EOF.
2. **Defensive:** Add rendering fallback that shows a red X error box
with "Failed to read files" when `ReadFilesResult::Success` has empty
`file_contexts`, preventing empty boxes for any future edge case.
3. **Tests:** Updated existing test and added two new tests covering
out-of-bounds ranges on non-empty files.
## Testing
- Updated `empty_file_with_ranges_produces_no_segment` →
`empty_file_with_ranges_produces_empty_segment` (expects 1 segment with
empty content)
- Added `range_past_eof_produces_empty_segment` — 5-line file, range
10..15
- Added `multiple_ranges_some_past_eof` — 5-line file, ranges [1..3,
10..15]
- All 23 text_file_reader tests pass
- `cargo fmt` and `cargo clippy` clean
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-BUG-FIX: Fixed read_files tool showing an empty box when the
LLM requests line ranges beyond the end of a file.
---
[Conversation](https://staging.warp.dev/conversation/ef9f9688-ca1e-4eb3-b29a-35c5c13e80da)
| [Plan](https://staging.warp.dev/drive/notebook/lAlU2uG6KN5y96mdmk8wYL)
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Fixes#9381.
The OSS channel's `.desktop` file uses `Exec=warp-oss`, but Linux
packaging actually exposes the launcher as `warp-terminal-oss`:
- `script/linux/bundle_{deb,rpm,arch,appimage}` all set
`PACKAGE_NAME="warp-terminal$CHANNEL_SUFFIX"`, which yields
`warp-terminal-oss` for the OSS channel.
- The `deb` postinst (`resources/linux/debian/app/postinst.template`)
creates `/usr/bin/warp-terminal-oss`.
- The `rpm` spec (`resources/linux/rpm/app/warp.spec.template`) creates
`%{_bindir}/warp-terminal-oss`.
- The Arch `PKGBUILD` template installs `/usr/bin/warp-terminal-oss`.
- The AUR package (per the bug report) does the same.
So when a user clicks the WarpOSS application-menu entry, the launcher
tries to run a non-existent `warp-oss` and fails.
This PR updates `app/channels/oss/dev.warp.WarpOss.desktop`:
```
-Exec=warp-oss %U
+Exec=warp-terminal-oss %U
```
After the change, the OSS channel follows the same convention as every
other channel:
| Channel | `Exec=` |
| -------- | ------------------------ |
| stable | `warp-terminal` |
| preview | `warp-terminal-preview` |
| dev | `warp-terminal-dev` |
| local | `warp-terminal-local` |
| **oss** | **`warp-terminal-oss`** |
### AppImage compatibility
`script/linux/bundle_appimage` runs:
```sh
sed -i -E 's/Exec=warp-terminal/Exec=warp/' "$STAGE_DIR/usr/share/applications/$BUNDLE_ID.desktop"
```
Before this PR, the OSS line `Exec=warp-oss` did not match the pattern,
so the sed was a no-op for OSS. After this PR, `Exec=warp-terminal-oss`
is rewritten to `Exec=warp-oss`, which matches the bundled
`BINARY_NAME=warp-oss`. Behavior inside the AppImage is unchanged.
## Testing
- Validated all five channel `.desktop` files with
`desktop-file-validate` — all pass.
- Verified via grep that no source file referenced the old
`Exec=warp-oss` form, so this is the only place the value lives.
- Manually traced the bundling/install paths for deb, rpm, arch, and
AppImage to confirm the new value is correct in each context (described
above).
This is a packaging-data-only change (single line in a `.desktop` file)
— no Rust source is touched, no tests are affected.
## Server API dependencies
- [ ] Is this change necessary to make the client compatible with a
desired server API breaking change? — No, packaging-only fix.
## Agent Mode
- [ ] Warp Agent Mode
## Changelog Entries for Stable
CHANGELOG-BUG-FIX: Fixed Linux WarpOSS application-menu launcher
pointing to a non-existent `warp-oss` binary; the `.desktop` Exec line
now matches the installed `warp-terminal-oss` launcher.
## Description
Refactors `OrchestrationEventStreamer` so v2 orchestration SSE
connections are opened only for conversations that actually need them in
the current process.
## What
A conversation now subscribes to its SSE feed iff it has both:
- a real role in an orchestration tree — child (the conversation has a
parent agent) or parent (it has at least one registered child run_id),
and
- an active local consumer — an open agent view, or an `agent_sdk`
driver in CLI / cloud worker processes.
Solo conversations and passive views of remote runs (shared-session
viewers, remote-child placeholders) no longer subscribe. The streamer is
the single owner of the consumer registry and the eligibility decision;
consumers register/unregister around their lifetime and the streamer
re-evaluates eligibility at every state change.
Other lifecycle improvements:
- The `Success`-transition start trigger and the conversation-status
tracking it relied on are gone. Status is no longer part of the
subscription decision.
- A child's run_id is pruned from any tracked parent's filter when the
child conversation is removed; the parent's SSE is reconnected with the
smaller filter or torn down if it has no remaining role.
- The SSE `run_ids` filter is recomputed from current state on each open
/ reconnect.
Tech spec: `specs/review-sse-connection-strategy/TECH.md`.
## Why
The pre-rewrite lifecycle had three problems: wrong start trigger (only
fired on `ConversationStatus::Success`), wrong stop trigger (only on
conversation removal — abandoned parents kept live SSEs), and wrong
scope (every cloud-backed conversation self-registered, including
passive viewers of remote runs).
## Testing
- Unit tests in `orchestration_event_streamer_tests.rs` cover the
consumer/role gate, restore-on-startup cursor merging, mid-flight
deletion (both Ok and Err paths), and SSE reconnection when children are
discovered after the connection is open.
- `cargo fmt`, `cargo clippy -p warp --lib --tests -- -D warnings`, and
the streamer test module all pass locally.
- Manual validation runbook (sections A–F + spot-checks) is documented
in TECH.md.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-IMPROVEMENT: Tighten orchestration event subscription scope so
SSE runs only for active parent and child agent runs.
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Adds `@vkodithala` as a co-owner on skills, MCP, and long-running shell commands in `.github/STAKEHOLDERS`, so issue and PR triage routes those areas to me as well.
- Skills: `/app/src/ai/skills/`
- MCP: `/app/src/ai/mcp/` and `/crates/mcp/`
- Long-running shell commands: `/app/src/ai/blocklist/action_model/execute/shell_command.rs` (new entry)
## Linked Issue
N/A — focus area / ownership update.
## Testing
Documentation-only change to `.github/STAKEHOLDERS`; no code or tests affected.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz <oz-agent@warp.dev>
## Description
With my server changes in [this](https://github.com/warpdotdev/warp-server/pull/10678) PR, we now accept an explicit user query mode in ambient agent queries sent via the public API. This PR passes `UserQueryMode`through ambient agent requests so CloudMode preserves `/plan` and `/orchestrate` semantics, and shares prefix highlighting helpers across local and CloudMode query rendering.
Keeps local and CloudMode prompt bubbles visually consistent, and includes a drive-by change to fix `/orchestrate` prefix highlighting in rendered queries in the blocklist.
## Testing
Tested manually. Demo here.
## Server API dependencies
- [ ] Is this change necessary to make the client compatible with a desired server API breaking change?
- [ ] Does this change rely on a new server API?
- [ ] Is this change enabling the use of a server API on client channels that rely on the production server?
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz [oz-agent@warp.dev](mailto:oz-agent@warp.dev)
## Description
`extension_for_content_type` in `app/src/ai/artifact_download.rs` only
mapped `image/jpeg` to a `.jpg` extension, but two adjacent code paths
already treat `image/jpg` (the non-standard alias still emitted by some
tools and CDNs) as an equivalent JPEG type:
- `app/src/util/image.rs:29` — `SUPPORTED_IMAGE_MIME_TYPES` lists both
`image/jpeg` and `image/jpg`.
- `app/src/terminal/input.rs:10044` — the paste-image handler matches
`\"image/jpeg\" | \"image/jpg\" => \"jpg\"`.
So an artifact served with `Content-Type: image/jpg` would pass the
supported-types check elsewhere in the app but get a missing/wrong
extension when saved through `artifact_download`. This patch lines that
one path up with the rest of the codebase by treating `image/jpg` as an
alias for `image/jpeg`, and adds a unit test that pins both spellings.
## Testing
- Added unit test
`extension_for_content_type_recognizes_image_jpg_alias` covering both
`image/jpg` and `image/jpeg`.
- `cargo fmt -p warp -- --check` ✅
- `cargo nextest` skipped locally — Metal toolchain isn't available on
my machine, same situation as #9277. CI will exercise the test.
## Server API
- [ ] Yes
- [x] No
## Agent Mode
- [ ] Yes
- [x] No
## Changelog Entries
- CHANGELOG-BUG-FIX: Fixed downloaded image artifacts served with
`Content-Type: image/jpg` getting the wrong file extension.
Co-authored-by: anshul-garg27 <13553550+anshul-garg27@users.noreply.github.com>
## Description
`language_by_filename` in `crates/languages/src/lib.rs` recognizes
`.html` but not the legacy three-character `.htm` extension. `.htm` is
widely produced by static-site generators and historical web tooling
(DOS 8.3 filename limits), and is already treated as an HTML/text file
elsewhere in the codebase: see `is_development_text_extension` in
`crates/warp_util/src/file_type.rs:225`, which lists `"html" | "htm"`
together.
Opening a `.htm` file in Warp's editor today shows "Language support is
unavailable for this file type" instead of HTML syntax highlighting.
This PR resolves the inconsistency.
```diff
- "html" => language_by_name("html"),
+ "html" | "htm" => language_by_name("html"),
```
## Testing
- Added `html_extensions_resolve_to_html` in
`crates/languages/src/lib_tests.rs` covering both `.html` and `.htm`.
The test calls `language_by_filename(Path::new("index.htm"))` and
asserts `display_name() == "HTML"`; fails on master, passes after the
change.
- `cargo fmt -p languages -- --check` passes locally.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-IMPROVEMENT: HTML files using the .htm extension now open with
HTML syntax highlighting in Warp's editor.
Co-authored-by: Suraj Gupta <39461854+szgupta@users.noreply.github.com>
## Description
The onboarding flow managed by `OnboardingCalloutModel` was getting
triggered when Warp runs in headless SDK/CLI mode. There is no real user
to interact with the callout in those runs, so the tutorial would
silently take over the input and discard the prompt the SDK had
submitted.
This PR adds an `AppExecutionMode::can_show_onboarding` gate (which
mirrors the other `is_app()`-based capability checks) and uses it to
skip every onboarding entry point in SDK mode:
- `Workspace::start_agent_onboarding_tutorial`
- `Workspace::dispatch_tutorial_when_bootstrapped`
- `Workspace::should_show_agent_onboarding`
- `Workspace::should_trigger_get_started_onboarding`
- `Workspace::check_and_trigger_onboarding`
In `App` mode behavior is unchanged.
## Testing
`cargo check -p warp_core` and `cargo check -p warp` both pass.
## Server API dependencies
No server changes.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-BUG-FIX: Don't trigger the agent onboarding tutorial when Warp
is running in headless SDK/CLI mode.
_Conversation:
https://staging.warp.dev/conversation/e7e67056-a174-4995-9fb0-54c104d09d12_
_Run:
https://oz.staging.warp.dev/runs/019dde8f-ff05-716f-8c3a-e7644e40f40d_
_This PR was generated with [Oz](https://warp.dev/oz)._
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
[APP-3805](https://linear.app/warpdotdev/issue/APP-3805/client-server-version-skew)
— handle client/server version skew for the SSH remote-server binary.
Previously the remote binary lived at a single unversioned path. When a
client updated but the remote still had an older binary, the two could
silently go out of sync.
This PR does three things:
1. **Version the installed path.** The binary is now written to
`{dir}/{binary_name}-{version}`, so any client-server drift becomes a
path miss and triggers a reinstall. The unversioned path is kept for
`cargo run` / `deploy_remote_server` dev loops.
2. **Check versions on handshake.** `initialize()` now compares
`server_version` against the client's release tag. On mismatch, the
manager deletes the stale binary, tears the session down, and emits
`SessionConnectionFailed` so the failed-banner path fires.
3. **Auto-update without a prompt.** When `check_binary()` misses but
the remote already has an install directory, we skip the "Install Warp
SSH tools?" modal and install directly with `is_update: true`. The
shimmer reads "Updating Warp SSH Extension..." instead of
"Installing...". Dev clients without a release tag fall through to the
normal prompt so they don't accidentally CDN-install over a
locally-deployed binary.
## Testing
- `cargo test -p remote_server`, `cargo clippy -D warnings`, `cargo fmt`
— all clean.
- Manual against `alokedesai@136.107.29.130`:
- Fresh install: modal → "Installing Warp SSH Extension..." → Ready.
- Reconnect with a newer client tag: handshake mismatch detected, stale
binary removed, reconnect reinstalls.
- Reconnect with an older client tag while a newer versioned binary is
on the remote: auto-update, no modal, "Updating..." shimmer.
- Forced install failure on the update path: failed banner renders.
## Server API dependencies
None — warp-server already supports `?version=` on `/download/cli`
(#10284).
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Surface the **`#oss-contributors`** Slack channel
([link](https://warpcommunity.slack.com/archives/C0B0LM8N4DB)) as the
dedicated place for contributors to chat with each other and the Warp
team in the docs new contributors actually read.
- **`README.md`** — adds a `[!TIP]` callout under "Open Source &
Contributing", and updates the "Support and Questions" bullet to point
at `#oss-contributors`.
- **`CONTRIBUTING.md`** — adds a `[!TIP]` callout near the top so
contributors see it as soon as they land, and updates the "Getting Help"
bullet at the bottom.
- **`FAQ.md`** — updates the "Where do I get help?" bullet.
The existing
[`go.warp.dev/join-preview`](https://go.warp.dev/join-preview) link is
preserved as the workspace on-ramp for people who aren't yet in the Warp
Slack.
## Testing
Docs-only change — rendered the markdown locally to confirm the
GitHub-flavored `[!TIP]` callouts and Slack/`go.warp.dev` links render
correctly.
## Server API dependencies
N/A — docs only.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
<!-- Docs-only change; no changelog entry. -->
---
[Conversation](https://staging.warp.dev/conversation/1011b077-6ef3-4516-857f-85043490d114)
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Simplifies the public-facing pull request template by removing
internal-only sections and guiding contributors toward the
issue-readiness workflow.
Changes:
- Removed the `Server API dependencies` section and its internal Notion
links.
- Removed the `Changelog Entries for Stable` section (internal release
process).
- Removed the testing-policy Notion link from the `Testing` section.
- Added a `Linked Issue` section with checkboxes asking authors to
confirm:
- The linked issue is labeled `ready-to-spec` or `ready-to-implement`.
- Screenshots or a short video of the implementation are included where
appropriate.
- Added a `Screenshots / Videos` section as a place to attach that
media.
## Testing
Documentation-only change; verified the rendered template via `git
diff`.
_Conversation:
https://staging.warp.dev/conversation/7821ed8c-960f-406d-bec1-485a6c540873_
_Run:
https://oz.staging.warp.dev/runs/019dd545-1271-74cb-81ad-2545e30fb1fc_
_This PR was generated with [Oz](https://warp.dev/oz)._
---------
Co-authored-by: Oz <oz-agent@warp.dev>
### Description
Spotted while running another doc audit: `app/src/persistence/README.md`
still describes the migration workflow in terms of the pre-open-source
layout. `schema.rs` and `schema.patch` actually live under
`crates/persistence/` now, and the doc also still tells contributors to
`cd <warp-internal repo>`.
Three small text-only fixes:
- `app/src/persistence/schema.rs` → `crates/persistence/src/schema.rs`
- `app/src/persistence/schema.patch` → `crates/persistence/schema.patch`
- `cd <warp-internal repo>` → `cd <repo root>` (this is the public repo
now; contributors clone it under whatever name they pick)
I deliberately left the `our fork of diesel_cli` paragraph alone —
`script/install_cargo_build_deps` calls `cargo binstall --force -y
diesel_cli` which suggests it currently uses upstream, but I'd rather a
maintainer confirm whether the bundled-SQLite behavior the README claims
is still accurate before rewording that section.
### Testing
Markdown only — nothing to run.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
None.
---------
Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
### Description
The env_vars README ("up-to-date as of 6/26/2024") still references
three filenames that have moved or been renamed in the meantime. The
prose description of each file still matches the actual contents — only
the filenames changed.
| README path | Actual path |
|---|---|
| \`app/src/server/update_manager.rs\` |
\`app/src/server/cloud_objects/update_manager.rs\` |
| \`command_dialog/view.rs\` | \`command_dialog/command_dialog_view.rs\`
|
| \`section_headers_and_footers.rs\` | \`fixed_view_components.rs\`
(still defines \`render_trash_banner\` and \`render_save_button\`) |
I deliberately left the rest of the README alone — the other paths it
points at all still exist (verified locally with \`test -f\`).
### Testing
Markdown only — nothing to run.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
None.
Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
### Description
Two README files in \`crates/\` had typos and one had an ambiguous file
reference:
**\`crates/warpui_core/README.md\`**
- \"to do describe\" → \"To describe\"
- \"appearence\" → \"appearance\"
- \"precicely\" → \"precisely\"
- \"handlign\" → \"handling\"
**\`crates/lsp/README.md\`**
- \"implmentation\" → \"implementation\"
- The README said \"See main.rs for an example implementation\" but
there is no \`main.rs\` in \`crates/lsp/src/\`. The example actually
lives at \`crates/lsp/examples/rust-lsp/main.rs\`, so I made the path
explicit.
Doc-only changes.
### Testing
Markdown only.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
None.
Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
## Description
Renames a misspelled identifier (`delimeter` -> `delimiter`) across two
modules. Pure rename: 2 files, +9/-9 lines, no behavioral change.
**`app/src/env_vars/mod.rs`** - 6 changes:
- `pub fn export_variables(&self, delimeter: &str, ...)` -> `delimiter`
(parameter name)
- Internal call site
- Private `serialize_variables_internal(..., delimeter: &str, ...)`
parameter
- Three doc comments referencing the parameter
**`app/src/external_secrets/mod.rs`** - 3 changes:
- `static ref WARP_SECRET_DELIMETER` -> `WARP_SECRET_DELIMITER` (the
constant *identifier*)
- Two usages of the constant
### What is intentionally preserved
The **string literal value** `"/warp-secret-delimeter/"` on line 22 is
**kept as-is**. It is the runtime separator embedded in the `lpass
--format=%an{}%ai` command and split back out of lpass's output
(`line.split(*WARP_SECRET_DELIMITER)`). Changing the value would mean
output emitted with one delimiter is parsed with another, breaking
LastPass secret enumeration. Only the Rust identifier name is corrected;
the on-the-wire token is unchanged.
### Caller analysis
All three external call sites of `export_variables` (in
`drive/index.rs`, `drive/export.rs`, `terminal/input.rs`) use positional
arguments. Rust does not have named arguments, so the parameter rename
is invisible to callers and breaks nothing.
### Related
The comment `// Used as a delimeter to separate metadata` on line 20 of
`external_secrets/mod.rs` is deliberately left for PR #9404 (the round-3
typo bundle), which already includes that fix. Different lines, no
conflict.
## Testing
Pure identifier rename; no logic touched. The string-literal
preservation note above is the only correctness-relevant detail.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-authored-by: BennyWaitWhat <BennyWaitWhat@users.noreply.github.com>
### Description
\`docker/linux-dev/README.md\` still referenced the private
\`warp-internal\` repository in two places (a sentence about the repo
root, and a comment in the docker-run snippet). External contributors
following this doc would be looking for a repo they can't access.
Updated:
- \"You'll run all of these commands from the \`warp-internal\`
repository's root directory.\" → drop the repo name (\"the repository's
root directory\").
- \"This can be the \`warp-internal\` repository or some parent
directory of your choice.\" → \"the \`warp\` repository or some parent
directory of your choice.\"
Doc-only.
### Testing
Markdown only.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
None.
Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
## Summary
- Ignore `.claude/worktrees/` so Claude Code worktrees created under
`.claude/` aren't surfaced as untracked files.
## Test plan
- [x] `git status` no longer shows `.claude/worktrees/` entries when a
worktree exists there.
## Description
Adds Block's [Goose](https://github.com/block/goose) to the `CLIAgent`
enum so that running `goose` in a Warp terminal triggers the CLI-agent
toolbar, status, brand color, and icon — the same wrapper experience the
other recognized agents (Claude Code, Codex, Gemini, Amp, Droid,
OpenCode, Copilot, Pi, Auggie, Cursor) already get.
Without this change, `goose` runs as a plain terminal command and none
of the wrapper UI activates, even though the rest of the CLI-agent
infrastructure works fine for it once detection is in place.
Goose is wired in as a third-party agent without a first-party plugin
(mirroring Pi / Copilot / Cursor):
- No `CliAgentPluginManager` — falls through to the `None` arm in
`plugin_manager_for_with_shell`
- No `CLIAgentSessionHandler` — falls through to the `None` arm in
`create_handler`, and is implicitly excluded from `is_agent_supported`
via `matches!`
- Default `Inline` rich-input submit strategy
The `enum_iterator::Sequence`-driven detection in `CLIAgent::detect`
picks `goose` up automatically from `command_prefix()`, so no detection
plumbing is needed beyond the variant.
### Files touched
| File | Change |
|---|---|
| `app/src/terminal/cli_agent.rs` | New `GOOSE_COLOR` const (`#101010`),
`Goose` enum variant, match arms in `command_prefix`, `display_name`,
`icon`, `supported_skill_providers`, `brand_color`, `From<CLIAgent> for
CLIAgentType` |
| `app/src/server/telemetry/events.rs` | `CLIAgentType::Goose` |
| `crates/warp_core/src/ui/icons.rs` | `Icon::GooseLogo` + path mapping
`bundled/svg/goose.svg` |
| `app/assets/bundled/svg/goose.svg` | Official Block/Goose logo
(Apache-2.0), re-saved with the bundled-SVG `#FF0000` placeholder fill
so the runtime icon renderer applies the brand color |
| `app/src/terminal/cli_agent_sessions/plugin_manager/mod.rs` | Add
`CLIAgent::Goose` to the no-plugin-manager arm |
| `app/src/terminal/cli_agent_sessions/listener/mod.rs` | Add
`CLIAgent::Goose` to the no-handler arm |
| `app/src/terminal/view/use_agent_footer/mod.rs` | Add
`CLIAgent::Goose` to the `Inline` rich-input submit strategy arm |
| `app/src/terminal/cli_agent_tests.rs` | Add `("goose",
CLIAgent::Goose)` to `test_detect_known_agents` |
## Testing
Added `("goose", CLIAgent::Goose)` to the existing
`test_detect_known_agents` table — this is the standard regression
coverage pattern used for every other agent in this file. The test
exercises `CLIAgent::detect("goose", None, None, ctx)` and asserts it
returns `Some(CLIAgent::Goose)`.
The compiler enforces correctness for everything else: every
non-catch-all `match` on `CLIAgent` must list every variant
exhaustively, so any missed match arm would be a build failure rather
than silent wrong behavior at runtime.
**Local presubmit note:** `cargo fmt --check` passes locally. The full
`./script/presubmit` requires the Metal Toolchain (not just Xcode) to
compile shaders during the `warpui` build, and on this machine the asset
downloads but doesn't activate without further intervention. Relying on
CI to run the full `cargo clippy --workspace --all-targets --tests -- -D
warnings` and `cargo nextest run --workspace`.
## Server API dependencies
This PR does not depend on any server API changes.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-IMPROVEMENT: Recognize Block's `goose` CLI agent — running
`goose` now activates the CLI-agent toolbar, status, brand color, and
icon like other recognized third-party agents.
Fixes#9038
## 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
The Warp Drive import flow lets users pick workflow (YAML) and notebook
(Markdown) files. The picker uses `FileType::Yaml` and
`FileType::Markdown` from `warpui_core::platform::file_picker`, which
previously listed only `yaml` and `md`. That doesn't match what the
importer is willing to ingest:
-
[`app/src/drive/import/nodes.rs`](https://github.com/warpdotdev/warp/blob/main/app/src/drive/import/nodes.rs)
(`TryFrom<&Path> for FileType`) accepts both `.yaml` and `.yml` for
workflows.
-
[`warp_util::file_type::is_markdown_file`](https://github.com/warpdotdev/warp/blob/main/crates/warp_util/src/file_type.rs)
recognises both `.md` and `.markdown` (`MARKDOWN_EXTENSIONS`).
- The import modal's helper text in `modal_body.rs` already advertises
`"md, yaml, yml"` to users.
The result: a user can drag-and-drop a `.yml` workflow or `.markdown`
notebook and it imports cleanly, but the file picker filter hides those
same files when they click "Choose files…". This change brings the
picker in line with what the rest of the import path already accepts.
I left `FileType::Image` alone — that one has a separate user-facing
contract (the theme creator body explicitly says \"(.png, .jpg)\"), so
broadening it would need its own design decision.
### Testing
- Added two unit tests covering both extensions for `FileType::Yaml` and
`FileType::Markdown`.
- `cargo fmt -p warpui_core -- --check`
- Couldn't run the full `cargo nextest` locally (Metal toolchain not
available on this machine), the change is well-scoped to a const-array
literal so risk is low.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
- Warp Drive import file picker now lists `.yml` and `.markdown` files
in addition to `.yaml` and `.md`.
---------
Co-authored-by: anshul-garg27 <anshul-garg27@users.noreply.github.com>
Co-authored-by: anshul-garg27 <13553550+anshul-garg27@users.noreply.github.com>
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
This PR seeds the trust and auth config files for the codex harness, so
that we don't get interactive dialogs re: trusting project folders or
setting up auth when running in an autonomous cloud agent context. This
is handled similarly to the Claude Code and Gemini settings configs.
Of note:
- Codex doesn't currently support recursively trusting repos, we
manually add trust to the `config.toml` for both the working dir and any
children git repos of that dir. This is relevant in the cloud agent case
since we create a `workspace/` dir and clone all environment repos into
that dir, but we want to make sure they're trusted as well.
- We currently hardcode the OpenAI base URL to the US endpoint—this is a
temporary stopgap to unblock dogfood testing because the staging API key
hits this endpoint, but the longer-term solution will be to have a new
dedicated `ManagedSecret` type that can take in both an OpenAI API key
and optionally a base URL to use it with.
## 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
-->
Added unit tests that cover setting up the settings files and making
sure that we don't clobber any existing settings.
Tested manually after removing all of my local codex config to make sure
that we don't get popups and can run queries correctly:
https://github.com/user-attachments/assets/3417234f-f0f2-40c6-bb66-bbfa524276ca
(Loom is having an incident but the show must go on, hence the QuickTime
video)
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
Explicitly identifies, in source files, which ones were inherited from
Alacritty when Warp was initially built, and separately bundles in the
Alacritty license.
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
WISOTT!
## 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
-->
The vibes are right. I'm sure there's some minor styling but no blockers
remain to start using it!
## 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>
