## Description
Migrates the conversation list UI/model plumbing to consume the new
`AgentConversationEntry` abstraction introduced downstack.
This keeps active agent, conversation, and task entries represented
through a shared entry layer so the list view can rely on entry-provided
labels, icons, timestamps, and selection state instead of duplicating
that logic in the view model.
## Linked Issue
None.
## Screenshots / Videos
Not included; refactor of existing conversation list behavior.
## Testing
- `cargo fmt --check`
- Skipped `cargo clippy --workspace --all-targets --all-features --tests
-- -D warnings` at user request.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz <oz-agent@warp.dev>:wq
## Description
Adds the new Built with Warp and Powered by Oz badge images to the top
badge row in the README.
## Linked Issue
N/A
- [ ] 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 — README-only change.
## Testing
- `cargo fmt -- --check`
- `cargo clippy --workspace --exclude warp_completer --all-targets
--tests -- -D warnings`
- `cargo clippy -p warp_completer --all-targets --tests -- -D warnings`
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Conversation:
https://staging.warp.dev/conversation/0819cd3b-0dfa-457f-aa38-f0bb1ad01c6d
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Co-authored-by: Safia Abdalla <captainsafia@users.noreply.github.com>
## Description
Add two new bundled skills gated to dogfood (Local/Dev) builds via
`resources/channel-gated-skills/dogfood/`:
- **verify-ui-change-in-cloud**: After a user-facing client change,
spawns a cloud agent with computer use via `run_agents` to verify the
change visually. Detects the current repo (warp-internal or
warp-external) and selects the correct environment.
- **test-warp-ui**: Guides a cloud agent through launching Warp with
`cargo run` and testing UI behavior using the `computer_use` tool. Used
by the cloud agent spawned by verify-ui-change-in-cloud.
No Rust code changes — both skills are auto-discovered by the
channel-gated build system.
## Testing
- `cargo test -p ai` passes (skill parsing tests)
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-authored-by: Oz <oz-agent@warp.dev>
## 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
Adds copy actions to the attached tab context menu so users can copy
tab/session metadata directly from the same UI surface where that
metadata is shown.
The menu now includes copy actions for available, non-empty metadata
when it makes sense for the current tab layout:
- Horizontal tabs show `Copy tab title` only, matching the metadata
visible in the horizontal tab strip.
- Vertical tabs grouped by tabs show copy actions for the tab title plus
available focused-session metadata such as branch, working directory,
and pull request link.
- Vertical tabs grouped by panes show copy actions sourced from the
active pane, including `Copy pane title` instead of `Copy tab title`.
All new copy actions use sentence casing, and unavailable metadata is
omitted from the menu rather than shown disabled.
## Linked Issue
- [ ] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [x] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
- Loom demo: https://www.loom.com/share/b57f7bfebea44a15b2703140db88c758
## Testing
Added integration coverage for the main layout variants:
- `test_tab_context_menu_copies_metadata` covers horizontal tabs. It
verifies that only the tab title copy action is present, and that
selecting it copies the tab title.
- `test_vertical_tab_context_menu_copies_metadata` covers vertical tabs
grouped by tabs. It verifies that the context menu can copy the branch,
tab title, and working directory for the tab/focused session.
- `test_vertical_pane_context_menu_copies_metadata` covers vertical tabs
grouped by panes. It creates a split pane with different metadata and
verifies that the menu copies the active pane branch, pane title, and
working directory.
Validation run:
- `./script/run` (bundled and launched WarpLocal.app)
- `./script/run` (bundled and launched WarpLocal.app)
- `PATH=/tmp/warp-corepack-bin:$PATH
/Users/zach/Projects/warp_3/target/debug/integration
test_tab_context_menu_copies_metadata`
- `PATH=/tmp/warp-corepack-bin:$PATH
/Users/zach/Projects/warp_3/target/debug/integration
test_vertical_tab_context_menu_copies_metadata`
- `PATH=/tmp/warp-corepack-bin:$PATH
/Users/zach/Projects/warp_3/target/debug/integration
test_vertical_pane_context_menu_copies_metadata`
- `cargo fmt --manifest-path /Users/zach/Projects/warp_3/Cargo.toml
--all --check`
- `PATH=/tmp/warp-corepack-bin:$PATH cargo nextest run --manifest-path
/Users/zach/Projects/warp_3/Cargo.toml --no-fail-fast --workspace
test_tab_context_menu_copies_metadata
test_vertical_tab_context_menu_copies_metadata
test_vertical_pane_context_menu_copies_metadata`
- `PATH=/tmp/warp-corepack-bin:$PATH cargo clippy --manifest-path
/Users/zach/Projects/warp_3/Cargo.toml --workspace --all-targets
--all-features --tests -- -D warnings`
Note: initial nextest/clippy attempts without temporary Corepack shims
failed in `command-signatures-v2` because the global Yarn version is
1.22.22 while that crate requires Corepack/Yarn 4.0.1. Rerunning with
temporary Corepack shims passed.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
CHANGELOG-IMPROVEMENT: Added tab context menu actions to copy visible
tab and pane metadata when available.
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Adds a new AgentConversationEntry abstraction designed to replace
ConversationOrTask.
ConversationOrTask requires a bifurcation between local and cloud
conversations that is prone to skew. Downstream of ConversationOrTask,
navigation policy (e.g. should clicking this item open a cloud mode
pane? or open a cloud transcript view?) and other behaviors are computed
and cached. With cloud conversation continuation and local->cloud
handoff, it makes less sense to do this bifurcation up front, and
instead introduce a unified abstraction that broadly represents an AI
conversation, whether its a local conversation started by the user, a
cloud ambient agent conversation, or a conversation for which we only
currently have server metadata (e.g. have not actually fetched
transcript contents from storage).
This refactor will make it easier to implement correct behavior for UI
that depends on a conversation's provenance.
This is the first PR in a 4 pr stack, introducing the abstraction itself
- but does not hook it into anythinganything. There is 1 master tech
spec and 4 more granular specs for each incremental PR.
## Description
Updates the workspace `mermaid_to_svg` git dependency to the latest
upstream commit.
- Old rev: `f7233f69965c59760fad98d684c786569814d821`
- New rev: `4761588218f747c07d72fd324efcd2032d873aaf`
This also refreshes the corresponding `Cargo.lock` entries for
`mermaid_to_svg` and its in-repo `dagre_rust` dependency.
## Linked Issue
N/A
## Screenshots / Videos
N/A — dependency bump only.
## Testing
- `cargo fmt`
- `cargo clippy --workspace --all-targets --all-features --tests -- -D
warnings`
Note: clippy completed successfully. During the run,
`command-signatures-v2` logged a non-fatal build-script warning that it
proceeded with stale generated command signatures JS.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Agent artifacts:
- Conversation:
https://staging.warp.dev/conversation/7967da60-8ae2-4747-9db4-3bb49f727a32
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! -->
For local -> cloud handoff, we should disable the harness selector (as
you can't go from a local warp conversation to a cloud claude
conversation, using the same conversation).
This PR just locks the selector to Warp, but if/when we implement
local->cloud for non-warp-harnesses we'll have to make the code respect
the harness that's kicking off the cloud run.
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
https://www.loom.com/share/845bedb3e7e040dca0bb1413f8364b45
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
Adds the client-side follow-up for the Git Operations AI enterprise/tier
policy:
- Adds `isGitOperationsAiEnabled` to the client GraphQL schema and
`WarpAiPolicy` fragments/models.
- Converts the new policy into the app-level workspace billing model.
- Gates Git Operations AI requests and the “Commit & Pull Request
Generation” setting on the billing policy instead of the previous
hardcoded enterprise client gate.
- Removes the stale TODO that asked for this client-side gate.
This is intended to pair with the server-side schema/policy change in
warpdotdev/warp-server#10798. Keeping this PR as draft until the server
field is available to clients.
## Linked Issue
N/A — client follow-up for the server GraphQL schema/policy PR.
## Screenshots / Videos
N/A — this is policy/schema wiring. The existing setting is hidden when
the new billing policy disables Git Operations AI.
## Testing
- `cargo fmt --manifest-path
/Users/edward/Repos/edward-update-git-ops-ai-schema/Cargo.toml --all --
--check`
- `cargo clippy --manifest-path
/Users/edward/Repos/edward-update-git-ops-ai-schema/Cargo.toml -p
warp_graphql_schema -p warp_graphql -p warp --all-targets --all-features
--tests -- -D warnings`
- `git --no-pager diff --check`
No new integration test added; this is a small billing-policy plumbing
change that reuses existing settings/request gates.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Agent conversation:
https://staging.warp.dev/conversation/281d784d-6c87-414f-89db-1b29f771f571
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Co-authored-by: MaggieShan <sshan.maggie@gmail.com>
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
After posting a demo of local -> cloud handoff, I get some feedback
(from peter, varoon, and ZL) that it would be better to just open the
cloud mode session in the same pane as the local conversation. This
makes sense to me, and we're still forking the conversation and opening
up a new cloud mode pane so it's not like this is a destructive action
(someone can just close the cloud mode view and re-open the local
conversation view).
Implements REMOTE-1557
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
demo: https://www.loom.com/share/d2f67ee4e15245959210ef41d1dfe7c6
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
Fixes APP-4263: the code review git operations header briefly showed
incorrect PR-related actions while PR info for the current branch was
still being refreshed.
`load_metadata_for_repo` returns `pr_info: None` because PR info is
fetched separately via `refresh_pr_info` (`gh pr view`). That made the
UI treat unknown PR state as "no PR" while the async lookup was in
flight, which could briefly show `Create PR`. With the handle-only
version, switching between two branches that both have PRs could also
briefly fall back from `PR #N` to disabled `Commit` before resolving to
`PR #M`.
### Fix
In `app/src/code_review/diff_state.rs`:
1. Track an in-flight PR lookup with `refreshing_pr_info_handle:
Option<SpawnedFutureHandle>` instead of storing PR staleness in
metadata.
2. Abort any previous PR lookup before starting a new one.
3. Carry forward cached `pr_info` through metadata refreshes so the
header does not clear to disabled `Commit` while the next branch's PR
lookup is pending.
In `app/src/code_review/code_review_view.rs`:
1. Gate `Create PR` on `!is_pr_info_refreshing()` so an unknown/pending
PR lookup is not treated as "no PR".
2. If cached PR info is being carried while a new lookup is pending,
keep the previous `PR #N` label visible but disable the button/menu item
with a "Refreshing PR info" tooltip so it cannot open a stale PR.
3. Once the lookup resolves, update the header to the new branch's `PR
#M`, `Create PR`, or disabled `Commit` state as appropriate.
## Testing
Not run in this update per request.
Expected/manual behavior:
- Main/master → feature branch: no `Create PR` flicker while `gh pr
view` is pending.
- Branch with PR → branch with PR: no disabled `Commit` interstitial;
previous PR label remains disabled until the new PR info resolves.
- Branch with PR → branch without PR: previous PR label remains disabled
briefly, then transitions to `Create PR` if the branch is eligible.
- Dropdown `Create PR` and commit-dialog create-PR intent remain
unavailable while PR info is refreshing.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
UPDATED LOOM:
https://www.loom.com/share/4c94527c09914af9b295e49b4719159a
## Description
We want to use the same new cloud mode setup UI for local -> cloud
handoff that we have for regular cloud mode setup. We also want to
immediately fork the entire conversation into the new cloud pane before
you've actually starting the cloud run.
The main change required to do this was to fork the conversation
on-chip-click instead of on-prompt-send (see the corresponding server PR
for this issue), as we don't want the forked conversation to get stale
if new prompts are sent to the old conversation between clicking the
chip and sending a prompt in the cloud mode window.
## Screenshots / Videos
https://www.loom.com/share/580624a891d64bec81f9642dda766583
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
On macOS, some Japanese IMEs (built-in macOS Japanese, Google Japanese
Input, etc.) commit a phrase mid-typing via a single
`interpretKeyEvents:` pass that fires `insertText:` (the just-committed
phrase) and then `setMarkedText:` (the next in-progress character). The
trailing `[self unmarkText]` in `keyDownImpl` was unconditionally
clobbering that freshly-set marked text in our state.
After that, the IME's internal state still held the queued character but
`WarpHostView`'s `markedText` was empty and `warp_marked_text_cleared`
had been dispatched. On the next keystroke (typically Enter
to commit), `wasComposing` was therefore `false`, so
`warp_handle_view_event` ran without the composing flag and the
keybinding system handled Enter as a command submission. The IME's
`insertText:` of the queued character arrived at the post-dispatch
insert path with `handled=YES` and was silently dropped.
The fix tracks whether the IME modified marked text via `setMarkedText:`
or `unmarkText` during the current `interpretKeyEvents:` pass, and skips
the trailing `unmarkText` if the IME has already touched
marked text in that pass — the IME has either cleared it (so our call
would have been a redundant `ClearMarkedText`) or replaced it with new
in-progress text we must preserve.
This change is contained to the macOS Objective-C IME plumbing in
`host_view.m`. The Linux/Windows IME path (winit `Ime::Preedit` /
`Ime::Commit` in `crates/warpui/src/windowing/winit/event_loop/mod.rs`)
is structurally different and not affected by this PR.
## Linked Issue
Fixes#7261
> Note: the issue body explicitly reports `Operating system (OS): macOS`
(`15.6（24G84）`), so the `os:linux` label appears to have been applied in
error during automated triage. This PR addresses the
macOS path only; please drop the `os:linux` label or relabel as `os:mac`
during review.
- [x] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [x] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
### Before Fix
https://github.com/user-attachments/assets/f3acf468-2860-4326-b8ab-f8ff4990d5a0
### After Fix
https://github.com/user-attachments/assets/a45d9c18-8619-4422-9406-e3cb66cc380e
## Testing
Manual verification on macOS 15.x with the macOS built-in Japanese IME
(Hiragana / Romaji mode):
1. Reproduced the bug on `master` with the steps from #7261 — typing
`漢字の入力（変換）が、` and pressing Enter dropped the trailing `、` and submitted
the buffer immediately.
2. Verified the fix on this branch with `cargo run --bin warp-oss` (with
`FeatureFlag::ImeMarkedText` enabled locally so inline preedit could be
observed). After the fix the queued `、` is preserved across
the split-commit, the next Enter commits it via the IME, and a
subsequent Enter submits the buffer as expected.
3. Sanity-checked dead-key composition (`⌥e` then `a` → `á`) on a US
keyboard layout to confirm the dead-key suppression branch in
`keyDownImpl` is unaffected.
4. Ran the presubmit checks locally:
- `cargo fmt --check` — pass
- `cargo clippy --workspace --exclude warp_completer --all-targets
--tests -- -D warnings` — pass
- `cargo clippy -p warp_completer --all-targets --tests -- -D warnings`
— pass
- `./script/run-clang-format.py -r --extensions 'c,h,cpp,m'
./crates/warpui/src/ ./app/src/` — pass
- `cargo nextest run --no-fail-fast --workspace --exclude
command-signatures-v2` — passes for the IME-relevant suites; the only
failures observed locally
(`settings::init::tests::test_migration_does_not_rerun_when_marker_present`
and the SSH-IAP integration suite) reproduce identically on `master` and
are unrelated to this change.
- `cargo test --doc` — pass
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
<!--
CHANGELOG-BUG-FIX: Fix Japanese IME losing the last character of a
phrase that ends right before a punctuation mark on macOS.
-->
## Description
We were running three steps in parallel with `futures::join!`
1. Check binary
2. Check old binary for autoupdate
3. Detect platform
This will end up using 3 control master connections. Since each
connection is a limited resource, this could cause these open failed
issues.
For now I am moving these to be sequential. I considered combining them
into one command and have some client side parsing to reconstruct the
results but I am not confident about that change with different shells
and potential error states. We could observe if latency with sequential
execution becomes a problem and decide if we want to further optimize
## Description
Fixes the remote-control toolbar chip text weight so it matches the
normal-weight agent footer display chips while preserving the shared
chip fill, border, and text color styling.
## Screenshots / Videos
<img width="414" height="66" alt="image"
src="https://github.com/user-attachments/assets/8ad5d08b-02e6-4137-9e0e-6dacd19e0a6d"
/>
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-authored-by: Oz <oz-agent@warp.dev>
## Problem
Sentry issue `WARP-CLIENT-DEV-NYY`: `panic: Invalid edit range
4042..3982` in `Buffer::edit`.
When the AI agent produces a multi-hunk V4A diff where one hunk's
matched range subsumes another's (e.g. a large deletion whose context
window overlaps a nearby single-line edit), `fuzzy_match_v4a_diffs`
produces `DiffDelta`s with overlapping `replacement_line_range` values.
When `CodeEditorModel::apply_diffs` later converts these to char offsets
and feeds them to `insert_at_offsets`, the editor's `Buffer::edit`
panics on the invalid range.
Confirmed via MAA conversation `d71bf84b` (request `b621adb3`): a
17-hunk V4A diff against `mod.rs` produced overlapping deltas (lines
46..71 subsuming 64..65).
## Fix
**Diff layer** (`crates/ai/src/diff_validation/mod.rs`):
- Added `deduplicate_overlapping_deltas()` — after matching all hunks,
sort deltas by start line and drop any delta whose range overlaps with a
preceding one.
**Editor safeguard** (`crates/editor/src/content/core.rs`):
- In `apply_core_edit_actions()`, skip any action whose anchor-resolved
range has `start > end` instead of panicking. Returns
`EditResult::default()` if all actions are skipped.
## Tests
- `test_v4a_maa_crash_d71bf84b_no_overlapping_deltas` — uses the exact
V4A hunks from the crash to verify the subsumed delta is dropped (1
delta survives, not 2).
- `test_insert_at_offsets_overlapping_ranges_skipped` — passes inverted
char-offset range (`4042..3982`) to `insert_at_offsets` and verifies the
buffer is unchanged (edit gracefully skipped).
Fixes WARP-CLIENT-DEV-NYY
The file picker capped combined filename + path length at 55 characters,
leaving significant horizontal space unused in wider popovers. Drops
that cap for the command palette file picker and switches the path text
to render a leading `…` (instead of a fade) when overflow does happen.
Also fixes a latent paint bug in `Start + Ellipsis` text clipping: the
ellipsis-reservation shifted glyphs leftward without compensating their
origin, so the leftmost visible glyph overlapped the ellipsis at the
same x. Adds regression-protection unit tests for the start-clipping
paint path.
Fixeswarpdotdev/warp#8709
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
What is a design buddy?
## 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`.
- [X] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
<img width="1774" height="1326" alt="Screenshot_redacted_2"
src="https://github.com/user-attachments/assets/596bb770-d64f-443c-9da9-30e4fe0bf727"
/>
## 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?
-->
Look at the PR.
## Agent Mode
- [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Used claude code.
<!--
## 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
<!-- 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
First half of Phase 2 of REMOTE-1370. Adds the GraphQL plumbing for
\`taskGitCredentials\` so the driver can call it in the next PR.
**Changes:**
- Add \`taskGitCredentials\` types to \`schema.graphql\` and add to the
\`clientQueries\` allowlist in \`client-schema.ts\`
- New \`task_git_credentials.rs\` cynic query file, following the
\`task_secrets\` pattern
- Add \`GitCredential\` struct and \`get_task_git_credentials\` to
\`AIClient\` trait + \`ServerApi\` implementation
No behaviour change — nothing calls \`get_task_git_credentials\` yet;
that's in the follow-on PR.
**schema.graphql approach:** \`yarn generate -p staging\` was run to
verify the new types, but the output was not committed wholesale because
the current staging server also has other unrelated schema changes
(removed \`freeAvailableModels\`, new \`VOYAGE_4_512\` EmbeddingConfig
variant, etc.) that are out of scope and would break existing Rust
bindings. Instead, only the \`taskGitCredentials\` types were
cherry-picked — the field names, nullability, and doc comments were
verified to be identical to what the server generates.
Warp-server staging is deployed with the new query.
Followed by: #10153.
## Linked Issue
Linear: REMOTE-1370
## Testing
- \`cargo build -p warp\` clean
- \`cargo fmt\` and \`cargo clippy\` clean
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Conversation:
https://staging.warp.dev/conversation/e16dc3e2-8e2f-4499-8c9b-59b200e17c50
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>
## Description
Fix local file tree blinking and reshuffling after connecting to an SSH
session.
**Root cause:** When a remote SSH session is active, the remote server
streams frequent
`FileTreeEntryUpdated { Remote }` events for every filesystem change on
the remote host.
The previous code called `rebuild_flattened_items()` on each such event,
which re-flattened
*all* roots (including local ones), causing the local file tree to
re-render on every remote
filesystem change — visible as constant blinking/reshuffling.
**Fix:** Add an optional `target_root` parameter to the core
`rebuild_flatten_items_impl`
method. When `Some`, only the specified root is re-flattened; all other
roots keep their
existing items untouched. Three thin wrappers provide the public API:
- `rebuild_flattened_items_for_root(path)` — single-root rebuild
- `rebuild_flattened_items()` — full rebuild (all roots)
- `rebuild_flattened_items_without(path)` — full rebuild excluding a
deleted path
Updated the following event handlers to use per-root rebuilds instead of
full rebuilds:
- `FileTreeEntryUpdated { Local }` — rebuilds only the affected local
root(s)
- `FileTreeEntryUpdated { Remote }` — rebuilds only the affected remote
root
- `RepositoryRemoved { Remote }` — no-op rebuild (root already removed),
avoids touching remaining roots
Skipping unchanged roots is safe because the rebuild is fully
deterministic given the same
`entry`, `expanded_folders`, and `item_states` — re-flattening an
unmodified root produces
an identical items list and selection index.
## Testing
- `cargo check -p warp --lib` passes cleanly
- Verified the three updated event handlers and the rename flow
(editing.rs) all route through `rebuild_flatten_items_impl` correctly
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
<!--
CHANGELOG-BUG-FIX: Fixed local file tree blinking/reshuffling when
connected to an SSH session
-->
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
This PR implements the UI for the local -> cloud handoff flow in the
client. This is done levaraging the workspace-discovery and snapshotting
functionality added in the PRs below this one. On chip-click, we
snapshot the conversation's touched files and repos, and create a new
cloud mode pane to kick off a run. When the user submits a query, we
kick that run off.
Don't over-index on the UI too much — in a follow-up PR I'll add the
conversation into the cloud mode pane and also re-use the full cloud
mode setup v2 UI.
The associated server PR for this client PR is here:
https://github.com/warpdotdev/warp-server/pull/10777
## 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/a6caa2c974e34b49b2b038a8019c062c
## 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! -->
We weren't properly checking/respecting 3p agent harness information for
cloud conversation transcripts when deciding which icon to display in
the conversation list, vertical tabs, and pane header.
## Screenshots / Videos
<!-- Attach screenshots or a short video demonstrating the change, where
appropriate. Remove this section if it is not relevant to your PR. -->
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Description
Adds the client-side orchestration config UI on plan cards, auto-launch
for matching `run_agents` tool calls, and per-conversation config
scoping. This builds on top of the Stage 1 confirmation card and shared
controls.
**Demo:** https://www.loom.com/share/18e96159e91641e3b6a78924ea1b9f76
### What
**Plan card config block** — An inline config block on plan cards with:
- Approval toggle (pill switch) controlling whether orchestration is
enabled
- "View details" expand/collapse for Cloud/Local picker, harness, host,
environment, and model dropdowns
- Vertical full-width layout matching the Figma mock
- Dirty-sync transport: config changes piggybacked onto the next
outbound request as `OrchestrationConfigUpdate`
**Auto-launch** — When the user approves a config and the agent sends a
matching `run_agents` tool call, the confirmation card is skipped and
agents spawn immediately. Deferred to stream completion via
`ActionBlockedOnUserConfirmation` to handle streaming timing.
**Per-conversation scoping** — Orchestration config moved from the
`AIDocumentModel` singleton to per-conversation `AIConversation` storage
(following the `todo_lists` pattern), preventing config from one
conversation leaking into another.
**Reactive config hydration** — `OrchestrationConfigSnapshot` messages
are processed inline in `apply_client_action()` as they arrive, rather
than scanning all messages on every streaming update. Scanning is only
used for conversation restore.
### Architecture
- `crates/ai/src/agent/orchestration_config.rs` — Rust-native types,
`matches_active_config()` with 15 unit tests
- `app/src/ai/blocklist/inline_action/orchestration_controls.rs` —
Shared controls (trait-based generic pickers) used by both the
confirmation card editor and the plan card config block
- `app/src/ai/document/orchestration_config_block.rs` — Plan card config
block view
- Config block and document view subscribe directly to
`BlocklistAIHistoryEvent::OrchestrationConfigUpdated` (no passthrough
relay)
## Testing
- 40 unit tests for `run_agents_card_view` (21 new covering
auto-launch/auto-deny decision logic)
- 15 unit tests for `orchestration_config` (matching, proto round-trips)
- 37 orchestration integration tests passing
- Manual validation against the [validation
checklist](https://staging.warp.dev/conversation/028e6a5d-0a9f-4e4d-84a6-b03f80a77331)
covering plan card UI, dirty sync, per-conversation scoping,
auto-launch, confirmation card, and edge cases
## Server API dependencies
- Relies on `OrchestrationConfigSnapshot` and
`OrchestrationConfigUpdate` proto messages (already deployed)
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
[Conversation](https://staging.warp.dev/conversation/028e6a5d-0a9f-4e4d-84a6-b03f80a77331)
| [Plan](https://staging.warp.dev/drive/notebook/xxRB6SLGbQc23j2NGObZsq)
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
Fixes APP-4385
We already have the SSH warpification open failed event. This enrich it
so we could track whether user has the remote server enabled when
running into this error
## Description
Fix terminal text selection no longer auto-scrolling downward when drag
exits the scroll container (block list).
**Root cause:** `LeftMouseDragged` events were subject to z-index
coverage checks in `DispatchedEvent::at_z_index()`. When the user
dragged downward past the block list, the cursor entered the area of
higher-z-index UI elements (input/footer), causing `is_covered()` to
return true and the drag events to be filtered out. This prevented the
block list element from receiving drag events, so its auto-scroll logic
(`mouse_dragged()`) never executed.
**Fix:** Bypass z-index filtering for `LeftMouseDragged` events in the
blocklist element specifically when selecting.
Fixes APP-3952
## Testing
Manual testing:
https://www.loom.com/share/0e81bc86229a4e0085b52253ca846346
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-BUG-FIX: Fixed terminal text selection not auto-scrolling when
dragging beyond bounds
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>
## Description
Restores the Slack `#oss-contributors` references that were
inadvertently dropped by #9580, and adds the Oz credits call-to-action
as a plain sentence (rather than a second TIP block).
## Linked Issue
N/A — fixes a regression from #9580.
## Testing
Visual inspection of the rendered README.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
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 is the second step to get local->client snapshotting working.
On the server, we have an endpoint to to prepare a snapshot (see [server
PR here](https://github.com/warpdotdev/warp-server/pull/10777),
providing pre-signed GCS endpoints to upload snapshot files. The same
server PR also adds fields on the `SpawnAgentRequest` to provide the
conversation id that we're forking from and the prep token that
identifies where we uploaded our snapshot files.
This PR adds the apparatus for us to use those endpoints, which we will
then use in the PR above this one to correctly snapshot and create our
local->cloud handoff run.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
Co-authored-by: Oz <oz-agent@warp.dev>
## Summary
Two workflow checkouts request the full repo history via `fetch-depth:
0` but never use it. Falling back to the default shallow clone speeds
them up at no behavioral cost.
## Analysis
I scanned every `fetch-depth: 0` site in `.github/`:
| Site | Why set | Needed? |
|---|---|---|
| `check_approvals.yml:19` | `git merge-base` + `git diff` between
base/head | **Yes** — merge-base across long-lived branches needs deep
history. Already mitigated with `filter: blob:none`. |
| `create_release.yml:1623` | Feeds `warpdotdev/generate-changelog` |
**Yes** — changelog walks tag history. |
| `feature_flag_cleanup.yml:30` (analyze) | Agent prompt instructs `git
blame` of `Cargo.toml` | **Yes** — blame needs full history. |
| `feature_flag_cleanup.yml:161` (cleanup) | None — agent prompt only
says "clean up references" / "remove from enum" / "modify code" | **No —
removed** |
| `feature_flag_cleanup.yml:218` (create_pr) | Applies a patch then runs
`peter-evans/create-pull-request` | Probably no, but kept conservative —
`peter-evans` only requires deep history when it must include prior
local commits. Worth a follow-up. |
| `delete_release.yml:95` | Job only does `git push
HEAD:refs/heads/<new>` then `git push --delete <old>` | **No — removed**
|
## Changes
- `feature_flag_cleanup.yml` — removed `fetch-depth: 0` from the cleanup
job. The Oz agent edits source files at HEAD; no git history operations
occur in the prompt.
- `delete_release.yml` — removed `fetch-depth: 0` from the delete job.
Renaming a branch is two server-side pushes; only the tip commit is
needed.
## Test plan
- [ ] CI passes on this PR.
- [ ] Next nightly run of `feature_flag_cleanup.yml` succeeds end-to-end
(analyze → cleanup → create_pr).
- [ ] Next manual `delete_release.yml` invocation succeeds (rename +
delete).
## Description
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
This PR is the first step in enabling local -> cloud handoff.
In order to do local->cloud handoff, we need to know which files and
repos to snapshot. Unlike with the cloud, we can't just check every repo
in the cloud agent's workspace because the agent isn't running in a
prepared VM in the local context.
Instead, we look back at the agent's most recent n tool calls (started
with 500 but we could easily change this) and extract out the file and
repo paths that the agent has touched from these tool calls (deduping
for files that are tracked in a repo). We specifically only check file
editing tool calls, as we don't want to snapshot a file that was just
read.
This is best-effort and is not guaranteed to capture everything we need,
but we can easily add more and better capturing as we need it.
## 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
<!-- Please remember to add your design buddy onto the PR for review, if
it contains any UI changes! -->
WISOTT. Follows precedent for defining keys in the keymap context and
uses existing function for determining whether this keybinding should be
active.
Defaults to unset - I wasn't sure of a good keybind for this and don't
think it warrants a default.
## 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?
-->
Ran locally, set a keybinding (cmd + alt + I), and then observed toggle
behavior.
## Agent Mode
- [x] 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...}}
-->
CHANGELOG-IMPROVEMENT: The conversation details panelcan now be opened
and closed with a configurable keyboard shortcut.
## Description
[Demo](https://www.loom.com/share/943140c634704c67b878b1815639aaaf)
1) Use the queued query UI for cloud mode initial query and follow-ups. Clean up old optimistic pending user query rich content machinery.
2) Properly hook setup commands for follow-up execution environment setup into the requested command-like setup command UI.
## Description
Fixes https://github.com/warpdotdev/warp/issues/9846 by making sure we
don't overwrite with an empty entry if we have a lazy loaded index.
## Linked Issue
https://github.com/warpdotdev/warp/issues/9846
- [x] The linked issue is labeled `ready-to-spec` or
`ready-to-implement`.
- [x] Where appropriate, screenshots or a short video of the
implementation are included below (especially for user-visible or UI
changes).
## Screenshots / Videos
https://www.loom.com/share/0213603002f84250b6366d99cb938a5c
## Testing
Locally tested:
https://www.loom.com/share/0213603002f84250b6366d99cb938a5c
## Agent Mode
- [x] 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...}}
-->
Closes#9196.
### Description
Two `show_code_review_button` gates were dropping panel-open requests on
the floor when the user had hidden the toolbar button:
**1. Data-path gate at `Workspace::setup_code_review_panel`
(`view.rs:7982`)**
```rust
if !*TabSettings::as_ref(ctx).show_code_review_button {
return;
}
```
`update_right_panel_open_state` calls into this whenever the right panel
is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the
early return silently swallowed every explicit user action.
**2. Render-path gate at `Workspace::render_config_panel` and
`render_config_panel_maximized` (`view.rs:18981` / `19040`)**
```rust
if !item.is_available(app) || !item.is_panel() { return None; }
…
if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; }
```
`HeaderToolbarItemKind::is_available` for `CodeReview` returns
`*TabSettings::as_ref(app).show_code_review_button.value()`
(`header_toolbar_item.rs:89`). So even after fix#1 set
`pane_group.right_panel_open = true` and `setup_code_review_panel` ran,
the next render frame saw `is_available() == false` and returned `None`
— the `right_panel_view` was never added to the layout.
This second gate is what @moirahuang flagged when their local repro
still showed nothing happening after the first fix landed. The data was
correct; the panel was just never composed into the UI.
### Fix
1. **Drop the early return at `setup_code_review_panel`.** The setting
is meant to gate only the toolbar button's visibility (already enforced
correctly by `header_toolbar_item.rs::is_available`, which feeds
`render_header_toolbar_button` at `view.rs:17276`).
2. **Switch panel-render call sites from `is_available` →
`is_supported`.** `is_available`'s own doc-comment says it's
specifically *"Whether this item should be shown in the **toolbar** —
checks both `is_supported` and user show/hide preferences."* Using it to
gate panel rendering conflates two unrelated concerns. Panel rendering
should only care about whether the feature is compiled in
(`is_supported`), not whether the user has hidden the toolbar button.
For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For
the other variants in the same match (`TabsPanel`, `ToolsPanel`),
`is_available` already equals `is_supported` (default `_ => true` arm in
the inner match), so behaviour is unchanged. `AgentManagement` and
`NotificationsMailbox` return `None` unconditionally inside
`render_config_panel`, so the change is moot for them too.
### Caller audit for `setup_code_review_panel`
5 call sites in `view.rs`:
1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab
already had `right_panel_open == true`.
2. `view.rs:8136` — `update_right_panel_open_state` with `should_open ==
true`. **The diff-button path** that #9196 is about.
3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open`
already true.
4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open`
already true.
5. `view.rs:14458` — session env update, gated on `right_panel_open`
already true.
None of these need the `show_code_review_button` gate — they're either
explicit user actions or gated on `right_panel_open` already being open.
The toolbar button toggle continues to do its job at
`render_header_toolbar_button` independently.
### Testing
Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon)
against `WarpOss.app` built from this branch:
1. Settings → "Show code review button" → **OFF**
2. `echo "x" >> README.md` inside a git repo
3. Click the diff stats chip on the prompt (`+1 -0`)
**Result:** Code review panel opens on the right showing the diff, while
the toolbar button stays hidden — exactly the expected behaviour from
issue #9196. Inverse case (toggle ON) also verified: toolbar button
visible, panel still works the same.
- `cargo fmt -p warp -- --check` passes.
- `cargo nextest` skipped locally — Metal toolchain unavailable on my
machine, mirroring #9277. CI will exercise the change.
### Server API
No server changes.
### Agent Mode
Not applicable.
### Changelog Entries
`CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens
the code review panel even when the toolbar's "Show code review button"
toggle is disabled (regression from a recent release).
Co-authored-by: anshul-garg27 <13553550+anshul-garg27@users.noreply.github.com>
## Description
Closes [APP-3595](https://linear.app/warpdotdev/issue/APP-3595).
The conversation details side panel was previously only visible for
cloud Oz runs (a `TerminalView` had to expose an `AmbientAgentTaskId`).
Local Warp Agent conversations had no way to surface the same metadata
even though `ConversationDetailsPanel` and
`ConversationDetailsData::from_conversation` already supported that case
on web.
This PR makes the pane-header info button and the side panel available
for **any active AI conversation in a `TerminalView`** (cloud Oz runs
continue to work unchanged). Task-only sections (Run ID, Environment
details, setup commands, error message, inference/compute credit split)
stay hidden when there's no backing `AmbientAgentTask`; everything else
(status, working directory, conversation ID when persisted, run time,
credits, source prompt, artifacts, harness, creator) renders from the
active `AIConversation`.
### Behavior summary
- **Cloud Oz runs**: unchanged. Info button in pane header, auto-open on
`SessionReady`, all existing fields rendered.
- **Cloud non-Oz runs (Claude / Gemini)**: unchanged. Task-mode panel as
today.
- **Local AI conversations (native)**: a new info-button toggle is
visible whenever there's an active conversation and AI is enabled.
Clicking opens the panel populated from the active `AIConversation`.
Task-only sections are hidden because the data isn't available.
- The panel does **not** auto-open for local conversations — it
only opens when the user clicks the toggle. Auto-open behavior on
`SessionReady` is still scoped to cloud mode.
- The panel refreshes on
`BlocklistAIControllerEvent::FinishedReceivingOutput` for any active AI
conversation (previously: only when the view was an ambient agent), and
on relevant `BlocklistAIHistoryEvent` updates so
streaming/status/artifact changes flow through while the panel is open.
### Key code changes
- `app/src/ai/conversation_details_panel.rs`: lifted the
`#[cfg(target_family = "wasm")]` gates on `from_conversation`,
`CreatorInfo::from_uid_fallback`, and the `UserUid` / `UserProfiles`
imports so the helper compiles on native.
- `app/src/terminal/view.rs`: added
`TerminalView::has_active_local_ai_conversation` and
`TerminalView::can_show_conversation_details_ui`, used the broader
predicate in the render gate, and broadened the refresh hooks.
- `app/src/terminal/view/ambient_agent/view_impl.rs`: generalized
`fetch_and_update_cloud_mode_details_panel` to fall back to the active
`AIConversation` when there's no task ID.
- `app/src/terminal/view/pane_impl.rs`: lifted the toggle button
rendering out from under the `FeatureFlag::CloudMode` arm in
`render_header_actions`.
- `app/src/ai/conversation_details_panel_tests.rs`: added a unit test
asserting that `from_conversation` populates the local-conversation
fields the details panel renders (working directory, title, source
prompt, `LocalConversation` credits, `Conversation` mode).
## Testing
Manually tested:
https://www.loom.com/share/1ca886583b3340ea94842ce7202a3c57
- Added `test_from_conversation_populates_local_conversation_fields` in
`app/src/ai/conversation_details_panel_tests.rs`. All 5 tests in the
`conversation_details_panel` module pass.
- `cargo check -p warp --lib` succeeds.
- `cargo clippy -p warp --lib --tests --no-deps -- -D warnings`
succeeds.
- `cargo fmt -p warp` applied.
- Manual smoke test (recommended for reviewers): start a local Warp
Agent conversation in a terminal pane and verify the info button appears
in the pane header, opens the side panel populated with the
conversation's title, status, initial query, run time, credits, working
directory, and conversation ID (when persisted). Compare to a cloud Oz
run for parity.
## Server API dependencies
This change is client-only and does not depend on any server API
changes.
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
## Changelog Entries for Stable
CHANGELOG-IMPROVEMENT: Conversation details side panel is now available
for local Warp Agent conversations, not just cloud Oz runs. Click the
info button in the pane header to open it for any active AI
conversation.
_Conversation:
https://staging.warp.dev/conversation/c79b0062-c933-4c75-956d-b16f461656a9_
_Run:
https://oz.staging.warp.dev/runs/019ddaf6-a62a-7ef3-86f7-b80b8ac8b2c8_
_Plans_:
- _[APP-3595: Show conversation details panel for local
conversations](https://staging.warp.dev/drive/notebook/kId8vzGLitcHOj5IMwH4R8)_
_This PR was generated with [Oz](https://warp.dev/oz)._
---------
Co-authored-by: Oz <oz-agent@warp.dev>
## Description
We are seeing ~850 Sentry errors in 2 days
([WARP-CLIENT-BETA-STABLE-7JNH](https://warpdotdev.sentry.io/issues/7456268110/))
from doomed reconnect attempts after SSH disconnects caused by system
sleep / network loss.
When the Mac sleeps, the SSH TCP connection dies but the ControlMaster
process stays alive locally (no keepalives configured). The
`remote-server-proxy` reader task detects EOF and triggers reconnect,
but reconnecting through the same ControlMaster is futile since its TCP
connection is dead. Both attempts fail with "Response channel closed
before receiving a reply" and the errors get reported to Sentry.
**Root cause**: the reconnect flow had no way to distinguish a
recoverable disconnect (remote server process crashed, SSH connection
still alive) from an unrecoverable one (SSH connection itself is dead).
**Fix**: Add `is_reconnectable(exit_status)` to the `RemoteTransport`
trait so each transport can decide whether a reconnect is viable.
`SshTransport` returns `false` when the exit code is 255 (SSH
connection-level error) or the process was signal-killed, indicating the
ControlMaster connection is dead. `mark_session_disconnected` consults
the transport before entering the reconnect loop.
This is a required trait method (no default impl) so future transports
must explicitly consider reconnectability.
### Changes
- **`RemoteTransport` trait** (`transport.rs`): Added required
`is_reconnectable` method
- **`SshTransport`** (`ssh_transport.rs`): Implements `is_reconnectable`
— returns `false` for exit code 255 / signal kill
- **`RemoteServerManager`** (`manager.rs`): `mark_session_disconnected`
calls `transport.is_reconnectable()` before attempting reconnect;
extracted `finalize_disconnect` helper to deduplicate the
disconnect-and-emit pattern
## Linked Issue
- Sentry:
[WARP-CLIENT-BETA-STABLE-7JNH](https://warpdotdev.sentry.io/issues/7456268110/)
## Testing
- `cargo clippy` passes on both `remote_server` and `warp` crates
- All 48 `remote_server` tests pass
## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
[Conversation](https://staging.warp.dev/conversation/ead2a14e-5ddd-4fe6-9a04-5ce7f48ec84f)
<!--
CHANGELOG-BUG-FIX: Fixed unnecessary reconnect attempts for remote SSH
sessions after system sleep, reducing error noise
-->
## Description
Specs for remote codebase indexing based off of
https://docs.google.com/document/d/1G4sDjVwatYMQC-BHsR3OvtlX6De27HYel7H8SSJQyM8/edit?usp=sharing
## Testing
N/A spec only
## Agent Mode
- [x] 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...}}
We have some logic for selecting a new default model if the user's
current model is no longer available. However, this logic doesn't
account when a model is _disabled_, which is different from when a model
is _removed_.
This fixes our logic to account for model disablement.
