Apply V4A edits that only delete a blank line by warp-agent-staging[bot] · Pull Request #110 · warpdotdev/warp-for-benchmarks

warp-agent-staging · 2026-10-03T23:30:23Z

A forwarded V4A hunk that only deletes one blank line was counted as a no-op. Joining that matched line is "", which equals an empty replacement, so the deletion never applied.

Compare the line sequences instead. Adding a blank line already applied. Replacing a blank line with a blank line stays a no-op.

This is the client half of the server change that now forwards those hunks instead of rejecting them.

…ion for CLI-harness ambient tasks (warpdotdev#15801) ## Problem For a third-party-harness (e.g. Claude Code) ambient agent run, a shared-session-injected prompt/follow-up that arrives before the CLI harness session is fully live could fall through the Oz-only prompt path and create a brand-new native `AIConversation`. That conversation's server token then gets reported via `UpdateAgentTask`, silently overwriting the run's real conversation ID and permanently breaking follow-ups for that run (`could not update agent conversation ID: invalid state`, repeated on every retry until cancelled). This is the client-side slice of a cross-repo fix. We queue 3p follow-ups until the 3p harness starts. We also improve logging, function naming, and types ## Changes - `terminal_view_adaptor.rs`: `accept_agent_prompt` is now the single choke point that routes an incoming agent prompt to exactly one destination: a live CLI-harness PTY, a new `PendingCliHarnessPromptQueue` (for a task registered against a third-party harness whose session hasn't started a live PTY yet, detected via `LocalAgentTaskSyncModel::task_id_for_terminal_view` independent of session-start state), or Warp's native Oz harness for every other case. - New `PendingCliHarnessPromptQueue` singleton (`app/src/ai/blocklist/pending_cli_harness_prompt_queue.rs`): a minimal FIFO queue, keyed by `AmbientAgentTaskId`, holding text-only prompts (file attachments are dropped with a warning log, since CLI-harness PTY delivery doesn't support them) until the task's harness session starts. - `AgentDriver::subscribe_to_cli_agent_session_events`: drains the queue on `CLIAgentSessionsModelEvent::StatusChanged{InProgress}` — a genuine, plugin-reported confirmation the harness is already running, rather than the earlier `Started` event which fires at command-detection time, before the harness has processed anything. A bounded 8-minute fallback timer (below the ~10 minutes the server allows before expecting the agent to have started working) drains anyway if no qualifying event ever arrives; draining is idempotent, so the fallback is a silent no-op once the normal path has already delivered. If the fallback timer actually finds prompts to deliver, it logs a warning, since a healthy plugin reports `InProgress` almost immediately — this indicates a broken or missing plugin integration (e.g. a Codex session using only the OSC 9 notification fallback, whose events never map to `InProgress`). Each prompt is delivered as a genuine PTY follow-up via `TerminalDriver::send_text_to_cli`; the queue is cleared on `unregister_cli_agent_task_sync`. - `BlocklistAIController`: renamed `execute_agent_prompt_for_shared_session` → `execute_warp_agent_prompt_from_shared_session_injection` and `send_shared_session_query` → `send_warp_agent_prompt_from_shared_session_injection`, with doc comments clarifying these are now Oz/native-only, since third-party-harness routing is decided upstream in `accept_agent_prompt`. - Added a defense-in-depth guard in `send_warp_agent_prompt_from_shared_session_injection`'s no-token fallback: refuses to create a native conversation (and reports an error) for a task that is CLI-harness-backed, checking two independent signals — the runtime registration (`task_id_for_terminal_view`) and the task's stored config (`AmbientAgentTask::is_third_party_harness`) — so the check still holds even before a session ever registers, honoring the existing setup-failure-debug-bootstrap exception. - `LocalAgentTaskSyncModel` stays a pure task-state-sync model (the queueing responsibility moved to the new dedicated singleton above). - `HarnessSupportClient` and third-party harness runners (Claude Code, Codex, Gemini) now use the safer `ServerConversationToken` type instead of the client-local `AIConversationId` for third-party-harness conversation identifiers, since these conversations are never represented in `BlocklistAIHistoryModel`. - Added an unconditional receipt log at the top of the `NetworkEvent::AgentPromptRequested` handler in `terminal_view_adaptor.rs` (before the feature-flag check and any permission/routing logic), recording the request id, participant id, and whether a `server_conversation_token` was present, so every received shared-session prompt is observable regardless of how it's later routed or rejected. - Added/updated unit tests covering: `PendingCliHarnessPromptQueue` (FIFO drain, per-task isolation, clear), and the `LocalAgentTaskSyncModel` test suite trimmed of the now-removed queueing responsibility. ## Validation ### Roland manual testing using e2e test [Modified e2e tests](warpdotdev/oz-e2e-tests#14) to send multiple followups in succession while sandbox closed, along with warpdotdev/session-sharing-server#516. Claude code combines them in one prompt, while codex sends both individually. Both 3p harnesses queue until the first prompt is done. Not ideal but acceptable for now <img width="1486" height="1014" alt="Screenshot 2026-09-08 at 2 51 10 PM" src="https://github.com/user-attachments/assets/a2026b17-1092-47e8-8c70-1f4425274572" /> <img width="1489" height="1027" alt="Screenshot 2026-09-08 at 2 51 23 PM" src="https://github.com/user-attachments/assets/e5071a68-61c6-465f-9be5-fcddfc1c6c6b" /> - `cargo check -p warp` (lib and `--tests`), `cargo fmt -p warp --check`, and `cargo test -p warp --lib` filtered to the touched modules (`pending_cli_harness_prompt_queue`, `local_agent_task_sync_model`, `shared_session`, `terminal_view_adaptor`, `checkpoint_coordinator`, `codex_tests`, `snapshot_tests`, `agent_driver`/`driver`): 433 passed, 1 unrelated pre-existing flaky failure (`cloud_provider::gcp::tests::best_effort_command_is_killed_on_timeout`, passes in isolation) as of commit 82ea349, confirmed by the orchestrating agent on a machine with sufficient memory (this sandbox OOMs partway through compiling the `warp` crate on every attempt). - `cargo fmt -p warp --check`: clean as of the latest commit. - Latest commit's (ae44f90) compile/test status not yet independently re-verified due to the sandbox's memory limit; manual review confirms no dangling references to removed/renamed symbols.   Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

…rrupt) (warpdotdev#15896) ## Description Supersedes warpdotdev/warp-internal#27904 (opened against the wrong repo; same commit, cherry-picked onto `master` here). Injected `cancel_conversation` control actions (session-sharing `PUT /sessions/control/{sid}`, used by warp-server's new `POST /agent/conversations/{cid}/interrupt` for conversation steering) are delivered to the sharer as `DownstreamMessage::ControlActionRequested` with `participant_id` equal to the sharer's own participant id — session-sharing attributes injected actions to the sharer, exactly as it does for injected agent prompts. The sharer-side `NetworkEvent::ControlActionRequested` handler in `app/src/terminal/local_tty/terminal_view_adaptor.rs` resolved the requester with `presence_manager.viewer_role(participant_id)`, which only consults present viewers. The sharer is never in its own viewer list, so every injected interrupt hit ``` Failed to get viewer's role during control action request ``` was rejected with `ControlActionFailureReason::InsufficientPermissions`, and `handle_shared_session_cancel_action` never ran — the turn kept going. Verified end to end on a local stack. This mirrors the existing sharer bypass in the `NetworkEvent::AgentPromptRequested` handler in the same file: if `presence_manager.sharer_id() == participant_id`, allow; otherwise require `viewer_role(...).can_execute()`. The warn log now includes the participant id, matching the prompt handler. **Viewer-originated cancels are unchanged.** Session-sharing still role-checks them in `try_send_control_action`, and the non-sharer branch here is the same viewer role check + `InsufficientPermissions` rejection as before. The bypass is strictly `participant_id == sharer_id`; the `None`-role case for non-sharer participants is not relaxed. Required by the conversation steering interrupt work: - warp-server: warpdotdev/warp-server#16958 - session-sharing: warpdotdev/session-sharing-server#517 (merged) ## Linked Issue N/A — part of the conversation steering interrupt work linked above. ## Testing - `./script/format --check` — pass - `cargo clippy -p warp --all-targets --tests -- -D warnings` — pass - No existing unit/integration tests cover the `ControlActionRequested` or `AgentPromptRequested` handlers in `terminal_view_adaptor.rs` (only the `network.rs` event forwarding is tested), so no test was added rather than building a new harness for this one-line-of-logic change. - End-to-end reproduction of the bug (injected interrupt → warn log → turn continues) was done on a local stack prior to this change; the fix should be re-verified against warp-server #16958 + session-sharing warpdotdev#517. - [ ] I have manually tested my changes locally with `./script/run` ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  Co-Authored-By: Warp <agent@warp.dev>

## Description Make every shared Sentry DIF upload fail the release step when `sentry-cli` is unavailable, the input path is missing, or three upload attempts fail. Failed uploads retain the CLI's stdout and stderr, retry after bounded 5-second and 10-second delays, and report the successful attempt clearly. The Windows upload remains in `release_windows`. That job already consumes PE and PDB artifacts from the separate `build_windows_binaries` job, so retrying a failed bundle job does not rebuild the binaries. Reviewer focus: the shared script's failure semantics and retry bounds. ## Linked Issue [DEVX-8538](https://linear.app/warpdotdev/issue/DEVX-8538/windows-sentry-pdbdif-uploads-fail-silently-and-cannot-be-retried) - [ ] No GitHub issue; this change is tracked in Linear. - [x] Screenshots are not applicable to this CI-only change. ## Testing - `cmp script/sentry_upload_dif.sh /workspace/warp-internal/script/sentry_upload_dif.sh` - `bash -n script/sentry_upload_dif.sh` - `./script/format --check` - `git diff --check` - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` No automated regression test is included by requester direction. - [ ] Local GUI testing is not applicable to this shell/CI change. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

## Description Adds a desktop, native-workspace-only **Join another team** row between the invite controls and Team members. **Browse teams** opens a centered, list-only chooser using standard modal chrome. Joining through `joinTeamInWorkspace` retains existing memberships, preserves the initiating window, and opens the joined team in a separate Warp window. The affordance and its window action are excluded from WASM. Replaces warpdotdev#15795 without carrying over its bottom inline list or enterprise leave-team changes. ## Linked Issue [APP-5806](https://linear.app/warpdotdev/issue/APP-5806/native-workspace-users-can-join-additional-open-teams-from-factory-and) - [x] The linked issue is ready to implement. - [ ] No feature proof is attached; the authenticated eligible flow remains unverified. ## Testing - `./script/format --check` - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` - `cargo test -p warp settings_view::teams_page::teams_page_tests` — 22 passed, including direct `JoinTeamInWorkspaceSuccess` coverage proving the source window remains unchanged, exactly one joined-team window is registered, and `WindowTeamChanged` targets only the new window - `cargo nextest run -p warp -E 'test(joining_a_workspace_team_retains_memberships_and_preserves_the_current_window) | test(test_open_new_window_for_team_creates_window_when_team_has_none) | test(native_workspace_member_on_a_team_can_join_another_open_team) | test(non_native_workspace_does_not_show_open_teams) | test(native_workspace_with_no_open_teams_does_not_show_join_another_team_row) | test(joined_team_disappears_from_open_teams_after_membership_refresh) | test(test_workspace_open_teams_survive_metadata_conversion)'` — 7 passed - `cargo build -p warp --bin warp` - WASM compile check deferred to CI because the sandbox's read-only Rust toolchain prevented installing `wasm32-unknown-unknown`. - Computer use — two attempts built and launched Warp, but service-account authentication cannot resolve user-scoped `openTeams`. - [ ] I have manually tested my changes locally with `./script/run` ### Screenshots / Videos   ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Native workspace users can browse and join another open team from Teams settings. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Oz <oz-agent@warp.dev> Co-authored-by: Warp <agent@warp.dev>

## Description Native-workspace members who are not team owners can now leave a team without losing workspace access. The Teams page gates this action on `NATIVE_WORKSPACES`, preserves the legacy enterprise workspace guard, and keeps native team owners on the transfer-ownership path instead of exposing Leave or Delete. The confirmation names the departing team and either the next team or the teamless state. The existing metadata refresh continues to re-scope every affected window and retains the reload-credit warning when applicable. ## Linked Issue [REV-2395](https://linear.app/warpdotdev/issue/REV-2395/enterprise-leave-a-team-without-leaving-the-workspace) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Linear uses the existing `triaged` workflow label for this item. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. The requester declined visual/computer-use verification because the required backend state is difficult to reproduce. ## Testing - `cargo nextest run -p warp -E 'test(/native_workspace_leave|native_workspace_owner_can_leave|native_workspace_team_owner|non_native_enterprise_workspace|every_departed_team_window/)'` — 8 passed. - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` — passed. - `cargo clippy -p warp --all-targets --tests -- -D warnings` — passed. - `cargo check -p warp` — passed. - `./script/format --check` and `./script/check_no_inline_test_modules` — passed. - [ ] I have manually tested my changes locally with `./script/run`. Declined for this PR because reproducing the native-workspace backend state is impractical; focused tests and static/build checks cover the changed paths. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Native workspace members can leave a team without losing workspace access.   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

…dotdev#15863) ## Description Preserve the selected managed-secret name and its captured team scope together throughout GUI and TUI orchestration launches, including delayed plan publication, autoexecution defaults, request construction, and remote and local child dispatch. Team changes immediately clear and reseed each affected window's credential selection from the new scope without leaking selections across windows. Local child task creation and inherited model/policy settings now derive from the same `StartAgentRequest.request_team_scope`. Behavior-level GUI and TUI regressions switch the window from Team A to Team B after capturing the request, drive the real dispatch endpoints, and require both task creation and child settings to remain on Team A. This is stacked on warpdotdev#15862 and contains the orchestration lifecycle portion split from warpdotdev#15813. ## Linked Issue REV-2383 - [ ] 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 - `./script/format` - `git diff --check` - `cargo check --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui` - `cargo test --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui ai::blocklist::action_model::execute::run_agents::tests` (22 passed) - `cargo test --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui ai::orchestration::remote_child::tests` (7 passed) - `cargo test --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui pane_group::pane::terminal_pane::tests` (6 passed) - `cargo test --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui orchestration_block::tests` (23 passed) - `cargo test --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui orchestration_model::tests` (24 passed) - Focused GUI endpoint regression: `local_child_dispatch_uses_request_scope_after_window_team_change` - Focused TUI endpoint regression with `warpui/test-util`: `local_dispatch_uses_request_scope_after_window_team_change` - Delayed publication regressions run individually: `delayed_dispatch_keeps_auth_secret_and_team_scope_together`, `delayed_local_dispatch_keeps_the_captured_team_scope` - `cargo clippy --manifest-path /workspace/warp/Cargo.toml -p warp -p warp_tui --all-targets --tests -- -D warnings` - Final test-power correction: focused GUI regression plus `cargo clippy -p warp --lib --tests --features warpui/test-util -- -D warnings` - Final hidden-child inheritance revision (`ce7d6d6a3`): `./script/format --check`; `git diff --check`; `cargo test -p warp --lib local_child_dispatch_uses_request_scope_after_window_team_change --features warpui/test-util` (1 passed); `cargo test -p warp --lib pane_group::tests --features warpui/test-util` (58 passed); `cargo clippy -p warp --all-targets --tests -- -D warnings`; negative control restoring the old current-window lookup fails at the inherited-Team-A assertion - [ ] I have manually tested my changes locally with `./script/run` (computer-use verification was declined; automated coverage only) ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Oz <oz-agent@warp.dev> Co-authored-by: Warp <agent@warp.dev>

## Description Enable shell widget handoff, native shell completions, and history ranking v2 in the app's default Cargo feature set, and remove them from the Preview-only feature list. Their existing runtime feature bridges remain unchanged. ## Linked Issue No linked issue. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement` — not applicable. - [ ] Where appropriate, screenshots or a short video of the implementation are included below — not applicable to feature-list changes. ## Testing Not run, per requester instruction. This changes only Cargo and runtime feature lists. - [ ] I have manually tested my changes locally with `./script/run` — not run, per requester instruction. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

## Description - Replace the Windows Acrylic boolean toggle with a `Window backdrop` dropdown containing No material, Mica, Acrylic, and Mica Alt. - Store the enum under the macro-derived `BackgroundBackdrop` key and `appearance.window.backdrop` TOML path while retaining the hidden legacy bool under `OverrideBlurTexture` / `appearance.window.override_blur_texture`. - Stage legacy `true` as non-persisted, non-explicit Acrylic before cloud reconciliation. After initial load, persist Acrylic only from reconciled legacy `true`, reset the transient value for `false`, and preserve explicit new values. - Show `Backdrop is not visible at opacity 100%` under the dropdown and update it immediately when opacity changes. - Apply the selected backdrop to existing and newly created Windows windows. ## Linked Issue No linked issue; this change was requested directly. ## Testing - [x] `./script/format` - [x] `./script/format --check` - [x] `cargo clippy --bin warp -- -D warnings` - [x] `cargo build --bin warp` - [x] `git diff --check` No unit tests are included per requester direction. Native Windows DWM backdrop behavior still requires manual verification on Windows. The requester will perform that verification on a Windows laptop. Per requester direction, no GUI integration test was added. - [ ] I have manually tested my changes locally with `./script/run` ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: [Windows] [Materials](https://learn.microsoft.com/en-us/windows/apps/design/signature-experiences/materials) are now supported for the backdrop of Warp windows in Settings > Appearance > Window > Backdrop.   ### Computer-use video recordings [![Navigating from Warp's authenticated terminal to Settings > Appearance, locating the Window backdrop control, opening its dropdown, and changing the selection multiple times to observe the closed control updating.](https://staging.warp.dev/api/v1/agent/artifacts/01a083c1-c33e-7a83-bb24-0df4965451e2/download)](https://platform.staging.warp.dev/artifacts/01a083c1-c03e-7725-86cf-b7aac3333156) **Warp Settings > Appearance Window backdrop navigation**: Navigating from Warp's authenticated terminal to Settings > Appearance, locating the Window backdrop control, opening its dropdown, and changing the selection multiple times to observe the closed control updating.   <details> <summary>Computer-use screenshots (2)</summary> ![Warp Settings > Appearance page with the Window backdrop dropdown open, showing all five options: No material (highlighted/selected), Automatic, Mica, Acrylic, Mica Alt.](https://staging.warp.dev/api/v1/agent/artifacts/01a083c0-390f-70ca-b524-7c3de3fd727b/download) Warp Settings > Appearance page with the Window backdrop dropdown open, showing all five options: No material (highlighted/selected), Automatic, Mica, Acrylic, Mica Alt. ![Warp Settings > Appearance page with the Window backdrop control closed, showing "Mica" as the currently selected option, confirming the closed control's label updates after a selection is made.](https://staging.warp.dev/api/v1/agent/artifacts/01a083c2-4304-7422-817c-bd074fe8c76e/download) Warp Settings > Appearance page with the Window backdrop control closed, showing "Mica" as the currently selected option, confirming the closed control's label updates after a selection is made. </details>   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

…5905) ## Description Adds a distinct **Remove from workspace** action to native-workspace team member rows for workspace admins and owners. Team-only admins keep only **Remove from team**, non-native workspaces keep their existing single removal action, and workspace owners remain protected from workspace removal. The confirmation dialog now explains the membership scope with the resolved member email and workspace name. Native team removal omits the reload/add-on credits warning, while non-native workspace-coupled removal retains the existing billing warning. ## Linked Issue [REV-2214](https://linear.app/warpdotdev/issue/REV-2214/workspace-admin-remove-from-workspace-action-on-team-members-pages) · [Slack origin](https://warpdev.slack.com/archives/C0BREN45G2D/p1789007618190829) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Linear is the source work item; there is no linked GitHub issue. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. Computer-use verification was explicitly declined for this change. ## Testing New regression test cases were reduced from 7 to 2 by reusing existing action-gating cases and consolidating copy and mutation-state branches. - `./script/format --check` - `./script/check_no_inline_test_modules` - `cargo check -p warp --tests` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo nextest run -p warp -E 'test(removal_confirmation_copy_matches_membership_scope) | test(test_remove_user_from_workspace_refreshes_state_only_on_success) | test(workspace_admin_without_team_role_can_promote_demote_and_remove) | test(team_admin_can_promote_and_remove_without_workspace_admin_role) | test(workspace_admin_without_native_workspaces_policy_can_manage_members)'` — 5 passed - `git diff --check` - [ ] I have manually tested my changes locally with `./script/run`. Computer-use verification was explicitly declined. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Workspace admins can now remove members from a workspace directly from team settings.   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

## Description Discovers nested build and package roots using detector-aligned markers, then pipelines root and nested `spacectl` detections through one shared concurrency-8 pool. A Tokio blocking task owns the synchronous `WalkDir` traversal and feeds a bounded capacity-8 channel, which removes resumable iterator state while preserving deterministic selection and backpressure. A whole-discovery child span is created under the active cache-setup span and entered on the blocking thread, with per-repository child spans preserving the trace hierarchy. Nested roots receive stable isolated cache paths; results return to canonical order before planning, all real mounts remain serial, and the global mount remains last. Traversal stays bounded to 10,000 directories and 32 child roots per repository, skips ignored and symlinked trees, and isolates per-root preparation or detection failures. Receiver drop stops the producer through failed `blocking_send` or `Sender::is_closed()` checks.   ## Linked Issue - [REMOTE-3146](https://linear.app/warpdotdev/issue/REMOTE-3146/discover-nested-build-tools-with-concurrent-spacectl-cache-setup) - Originating [Slack thread](https://warpdev.slack.com/archives/C0BDQDW8V5E/p1788767403717799) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement` — the work item is in Linear, where this GitHub-specific label does not apply. - [x] Screenshots or video are not applicable to this non-rendered build-cache change. ## Testing - `./script/format` - `cargo clippy -p build_cache --all-targets --all-features --tests -- -D warnings` - `cargo nextest run --no-fail-fast -p build_cache` — 48 passed - `cargo nextest run --no-fail-fast -p warp cache_setup` — 3 passed - `cargo run -p build_cache --example validate_spacectl -- empty` — reached complete validation without the prior missing-reactor panic; exited 1 because the sandbox detected `apt` and destructive mounts degraded - `cargo check -p warp --lib` - `git diff --check` - Verified worker `spacectl` is 0.12.2 (`df91f93`) - Live nested fixture detected root Rust, backend Go, and frontend npm modes with distinct stable cache roots; destructive mounts were unavailable in the sandbox. - Workspace Clippy was attempted but is blocked by unrelated existing all-features errors in `app/src/ai/execution_profiles` and dead-code failures. - Wasm Clippy was attempted but the sandbox lacks `wasm32-unknown-unknown`, and installing it is permission-blocked. `cargo tree -p warp --target wasm32-unknown-unknown -i build_cache` confirms the native-only crate is absent from the wasm graph; CI remains the compilation proof. - [x] Manually exercised nested discovery with the real worker `spacectl` binary. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Discover and cache build tools in nested repository directories. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Ben Navetta <ben@warp.dev>

…n load. (warpdotdev#15829) ## Description Loading an agent shared session in the WASM client could issue many equivalent requests while reconstructing the session. A captured page load included 37 identical ancestor-list requests, 4–5 detail requests per run, and 9 identical conversation-metadata requests. Several load-time events could re-enter these request paths before their first asynchronous response updated local state. Historical exchange replay also caused each completed exchange to attempt the same conversation-level metadata fetch. This change coalesces requests at the narrowest existing ownership points: - Track ancestor seed and task-harness requests while they are in progress. - Emit seeded child events only for newly discovered runs. - Make the legacy viewer metadata-fetch set act as an in-flight guard. - Track conversation metadata requests per conversation until completion. The task-harness path keeps its direct server request. The shared task cache does not provide request-specific completion callbacks or explicit freshness semantics, so using it here would expand the change and could return stale task state. Each commit contains one independent fix to simplify review. ## Linked Issue No linked issue. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — No linked issue. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — Not applicable; this PR changes request coordination only. ## Testing - `cargo fmt -p warp -- --check` - `cargo check -p warp` - No automated tests were added. These changes add narrow in-flight guards to existing request paths. - Manual validation is pending. The planned check is to reload the same shared session and compare a new HAR with the original request counts. - [ ] I have manually tested my changes locally with `./script/run` — Pending HAR-based validation in the WASM client. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed duplicate network requests when loading agent shared sessions. --------- Co-authored-by: Warp <agent@warp.dev>

## Description Removes Warp's pre-release Grok plugin manager so Warp no longer writes hook manifests, executable scripts, or version files into Grok configuration directories. Grok command detection, the normal CLI-agent footer and rich input, native OSC 9 completion, and compatible OSC 777 parsing remain unchanged. ## Linked Issue Closes warpdotdev#11727 - [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). ## Testing - `./script/format` - `cargo check -p warp --lib` - `cargo nextest run -p warp -E 'test(grok) | test(returns_none_for_unsupported_agents)'` — 8 passed - `cargo nextest run -p warp -E 'test(test_detect_known_agents)'` — 1 passed - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` - `cargo build -p warp --bin warp` - Computer use: ran a long-lived `grok` command and observed the normal CLI-agent toolbar controls without a notification install/update chip. - [ ] I have manually tested my changes locally with `./script/run` — tested the internal GUI with `cargo run --bin warp` instead. ### Screenshots / Videos   ### Computer-use screenshots ![Warp terminal running the long-lived \`grok\` process (window/tab title "grok"; block shows "Grok Build verification session" output), with the bottom footer/toolbar row visible showing: a circular restart icon, a "+" icon, a "/remote-control" chip, a "File explorer" chip, and a "Rich Input Ctrl G" chip, plus standard cwd/folder and panel-swap icons at the far right.](https://staging.warp.dev/api/v1/agent/artifacts/01a08bc6-1be6-7794-8819-ef0c9ed47852/download) Warp terminal running the long-lived \`grok\` process (window/tab title "grok"; block shows "Grok Build verification session" output), with the bottom footer/toolbar row visible showing: a circular restart icon, a "+" icon, a "/remote-control" chip, a "File explorer" chip, and a "Rich Input Ctrl G" chip, plus standard cwd/folder and panel-swap icons at the far right.   ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

…rpdotdev#15920) ## Description macOS computer-use recordings can render an initial frame but report a duration near 0 seconds and contain excessive duplicated frames. This adds an explicit FFmpeg output frame rate to the macOS `avfoundation` capture command, matching the configured capture rate. The AVFoundation demuxer exposes frames with a microsecond timebase. Without an output `-r`, FFmpeg interprets that as an extremely high constant frame rate (observed as 1,000,000 fps), duplicates frames to satisfy it, and produces a near-zero-duration MP4. The Linux recorder already constrains its output rate; this change brings the macOS path in line. ## Linked Issue Linked Linear issue here: https://linear.app/warpdotdev/issue/QUALITY-2068/macos-runner-computer-use-videos-are-0-seconds-and-unedited-vs-linux. ## Testing - `cargo fmt --all -- --check` — passed. - `cargo nextest run -p computer_use -E 'test(sets_output_frame_rate_to_capture_rate)'` — passed. - `cargo nextest run -p computer_use` — 81 passed, 2 skipped. - `./script/presubmit` — formatting passed, but the full build could not complete because the machine ran out of disk space while writing Rust metadata (`No space left on device`). The full build should be rerun in an environment with sufficient space. - No full GUI integration test was added because the regression is directly covered at the deterministic FFmpeg command-builder seam and the end-to-end capture requires a display-dependent macOS environment. - [ ] I have manually tested my changes locally with `./script/run` ### Screenshots / Videos Not applicable: this is a native FFmpeg command-line fix; end-to-end playback validation requires a macOS display environment. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed macOS computer-use recordings reporting near-zero duration. Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

@fbartho

…arpdotdev#14895) ## Description Creating a tab group opens the inline name editor *and* spawns a terminal. About a second later that terminal's bootstrap block becomes visible and takes focus, so the characters the reporter was still typing landed in the shell instead. **The part that isn't in the title.** Blur is treated as confirmation, identically to Enter: ```rust // app/src/workspace/view.rs EditorEvent::Blurred | EditorEvent::Enter => self.finish_tab_group_rename(ctx), ``` `finish_tab_group_rename` takes the buffer text, and if it is non-empty sets `group.name` and dispatches `workspace:save_app`. So @fbartho's three characters were not merely lost — they became the group's actual, **persisted** name. The keystrokes reaching the shell are the visible symptom; the silently committed truncated name is the one a user won't notice until later. That half is pinned by a test that fails on `master`: ``` assertion `left == right` failed: a rename interrupted by the terminal stealing focus must not be committed left: Some("Bui") right: None ``` ## What this changes Two layers, because removing the trigger and guaranteeing the invariant are not the same thing. **1. The terminal does not take focus while an inline rename editor is waiting for keystrokes.** This is the cause: with focus intact there is no blur, nothing is committed, and the keystrokes go where the user aimed them. `WorkspaceState` already tracks `tab_group_being_renamed` (it is even folded into `is_any_non_palette_modal_open`), but it lives on `WorkspaceView`, and `app/src/terminal/view.rs` has no reference to workspace state at all. This adds the narrowest bridge I found: a small singleton, `InlineRenameState`, that the workspace publishes to and the terminal reads — the same shape as the `SemanticSelection::as_ref(ctx)` usage a few lines away in that file. **Please weigh in, because this touches a documented policy.** `agents/specs/APP-4881-tui-starting-shell-indicator.md` states that `VisibleBootstrapBlock` updates focus immediately, "matching the GUI's terminal-focus policy". This carves an exception into that policy rather than treating it as a bug. The cost, so it is weighed fairly: a new singleton is one more global that every app-construction path must register. I missed the test harness first time and got `Cannot get singleton model ... that was never registered` — loud and immediate rather than silent, but a real coupling cost, not just a new file. **2. Blur discards the rename instead of committing it.** Layer 1 removes the trigger we know about; it does not make the data loss impossible. Any other non-user-initiated focus change — one that exists today and I haven't found, or one added later — would silently commit a fragment again, with nothing to catch it. I noticed this because the regression test kept failing after layer 1 landed: the test drives `EditorEvent::Blurred` directly, so it was asserting an invariant I had not actually implemented. Rewriting the test to match the implementation would have hidden the gap convincingly. Discarding on blur follows the convention used by rename inputs elsewhere (VS Code's rename box commits on Enter, cancels on Escape and on blur), and the two outcomes are not symmetric: discarding costs the user a retype, committing costs them their existing name, silently. **This does make tab groups differ from their siblings.** Tab and pane rename still commit on blur (`view.rs:1457`, `:1475`). They aren't reachable by this bug because neither races an auto-created terminal, so I left them alone rather than widening the change — but if you'd rather align all three, say so and I'll do it here. ## Linked Issue Fixes warpdotdev#14241 - [x] The linked issue is labeled `ready-to-spec` or `ready-to-implement` — labeled `ready-to-implement` on 2026-07-28. ## Testing Two tests in `app/src/workspace/view_tests.rs`: - `test_tab_group_rename_blur_does_not_commit_unfinished_name` — the regression above. Fails on `master` with `Some("Bui")`, and still failed with only layer 1 in place, which is what surfaced the need for layer 2. - `test_tab_group_rename_exits_release_terminal_focus_suppression` — exercises **both** exits, Enter and Escape. Suppressing terminal focus is only safe if every path out of a rename clears it again; if Escape left it set, terminals would silently stop taking focus for the rest of the session, which is a worse bug than the one being fixed and far harder to trace. `finish_tab_group_rename` had no direct coverage before this. The full `workspace::view::tests` suite is green (91 passed), including the existing tab-group assertions. ## Manual testing (local OSS build) Built `WarpOss.app` from this branch with `./script/run --dont-open` (default features, so `grouped_tabs` is on) and recorded the same interaction twice, on the same machine and the same window: create a tab group from the command palette, then type `Building` into the inline name editor one character at a time. **How the race was made reproducible, stated plainly.** The focus steal is driven by `ModelEvent::VisibleBootstrapBlock`, and `blocks.rs` only emits that when the new terminal's bootstrap block actually renders something — the oh-my-zsh update prompt in @fbartho's report is exactly such a case. A shell that starts silently never emits it, so the bug is invisible on a bare `zsh`. For the capture I launched the app with a throwaway `ZDOTDIR` whose `.zshrc` sources my normal one and then prints one line: ```sh [ -f "$HOME/.zshrc" ] && source "$HOME/.zshrc" sleep 1 print -r -- "[oh-my-zsh] Would you like to check for updates? [Y/n]" ``` Nothing else differs between the two takes — same window, same steps, same shell, same typing cadence. Only `app/src/terminal/view.rs` and `app/src/workspace/view.rs` are reverted to `master` for the BEFORE take. - **BEFORE (`master`)** — the terminal takes focus mid-word. The group is committed as **`Build`**, and `ing` lands in the shell: `zsh: command not found: ing`. - **AFTER (this PR)** — the group is named **`Building`**, and the shell receives nothing. The bootstrap line still prints; it just no longer steals focus. **One clip, both takes** (red title card, BEFORE, green title card, AFTER): <video src="https://raw.githubusercontent.com/maxmilian/warp/assets-14241/assets/14241-before-after.mp4" controls width="900"></video> Key frames, in case the player does not load: **Before — `master`** ![before: tab group committed as "Build", "ing" ran in the shell](https://raw.githubusercontent.com/maxmilian/warp/assets-14241/assets/14241-before.png) **After — this PR** ![after: tab group named "Building", shell untouched](https://raw.githubusercontent.com/maxmilian/warp/assets-14241/assets/14241-after.png) <sub>Media is served from a branch on my fork (`maxmilian/warp@assets-14241`) because the `gh` CLI cannot upload to `user-attachments`. Say the word and I will re-attach it through the web editor so it lives with the PR permanently.</sub> - [x] I have manually tested my changes locally with `./script/run` ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed a new tab group's terminal stealing focus while its name was being typed, which saved the partially-typed name. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Ben Holmes <bholmesdev@gmail.com> Co-authored-by: Warp <agent@warp.dev>

…dev#15906) ## Description Required for the conversation-steering interrupt e2e (warp-server warpdotdev/warp-server#16958, session-sharing warpdotdev/session-sharing#517, follows warpdotdev/warp-internal#27914). ### Staging evidence With the sharer bypass from #27914, a steering interrupt reaches the sharer as `ControlActionRequested { action: CancelConversation { server_conversation_token } }` and the turn is cancelled (no further LLM requests; `TOOL_RESULT cancel: cancelled` is carried with the next request). But the agent's in-flight tool command kept running to natural completion: `echo step-one; sleep 12; echo done-one` finished its full 12 s after the interrupt (`CommandExecutionFinished` ~12–13 s after start in every run). Product decision: an interrupt must terminate the running command as well as cancel the turn. ### Local stop vs. shared-session cancel (before this PR) * **Local stop kills the command.** The pill-bar Stop/Kill (`pane_group/pane/terminal_pane.rs`) and the second Ctrl-C after a Stop takeover (`view.rs` `ctrl_c_to_active_block`) both go through `TerminalView::stop_local_agent_conversation`, which calls `cancel_conversation_progress(ManuallyCancelled)`, releases an agent-controlled block via `set_user_control_for_teardown()`, and writes Ctrl-C (ETX) to the PTY. Rewind does the same. * **Shared-session cancel did not.** `terminal_view_adaptor.rs` → `BlocklistAIController::handle_shared_session_cancel_action` → `cancel_conversation_progress` only. For a running `RequestCommandOutput`, `ShellCommandExecutor::cancel_execution` just drops the block-finished / force-refresh oneshot senders so the action resolves `Cancelled`; nothing touches the PTY, so the child process runs to completion. ### Change * `NetworkEvent::ControlActionRequested { CancelConversation }` now calls a new `TerminalView::handle_shared_session_cancel_action(token)`, which resolves the token to the live conversation and then calls the existing `stop_local_agent_conversation`. Viewer-initiated stop and server-side steering both arrive through this handler, so both get the same behaviour. The local stop primitive is unchanged. * `BlocklistAIController::handle_shared_session_cancel_action` becomes `conversation_for_shared_session_cancel_action`: a pure resolver returning the live, **not-yet-finished** conversation bound to the token. This is a small deliberate tightening: a late/duplicate cancel for a conversation that already reached `Success`/`Error`/`Cancelled` is now a no-op (previously it only reset the sharer's input mode) instead of being able to flip the terminal status to `Cancelled` via the stop primitive. Expected result on staging: the command block finishes within ~1 s of the interrupt (exit 130) rather than at natural completion, and the tool result reports cancellation promptly. ## Linked Issue - [ ] 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 New unit tests in `app/src/terminal/view_tests.rs`: * `shared_session_cancel_action_interrupts_running_agent_command` — agent-requested command running in the active block; cancel writes exactly one ETX to the PTY and the conversation ends `Cancelled`. * `shared_session_cancel_action_releases_agent_controlled_command_before_interrupting` — CLI-subagent-controlled block (which would otherwise swallow the Ctrl-C in `write_user_bytes_to_pty`) is handed to the user for teardown, ETX is written, no auto-resume. * `shared_session_cancel_action_ignores_unknown_and_finished_conversations` — unknown token and already-`Success` conversation: no PTY write, status preserved. Commands run: * `./script/format` then `./script/format --check` — pass * `cargo clippy -p warp --all-targets --tests -- -D warnings` — pass * `cargo nextest run -p warp -E 'test(shared_session_cancel_action) | test(ctrl_c_after_stop_takeover) | test(ctrl_c_after_transfer_takeover) | test(completed_user_controlled_lrc)'` — 7/7 pass - [ ] I have manually tested my changes locally with `./script/run` (not run; needs the steering e2e on staging — see evidence above for the pre-change baseline) ## Follow-up: run state after interrupt (proposal, not implemented) Today `LocalAgentTaskSyncModel::map_conversation_status` (`app/src/ai/blocklist/local_agent_task_sync_model.rs`) maps `ConversationStatus::Cancelled` → `(AgentTaskState::Cancelled, "Cancelled by user")` and pushes it to warp-server, which runs `TransitionTaskToCancelled` (cancels a bound Factory task, notifies GitHub/Linear/Jira/lifecycle, expires queued follow-ups; the run becomes non-resumable once the session idles out). For a shared-session-originated cancel (steering interrupt or viewer stop) the desired run state is the idle shape a completed turn leaves: report `AgentTaskState::Succeeded` with status message `"Turn interrupted"`, while the transcript still shows the exchange as cancelled. **Why the reason isn't available to the sync model today.** The only place a `CancellationReason` is recorded is on the exchange, in `FinishedAIAgentOutput::Cancelled { reason }`, and only when an in-flight *stream* is cancelled (`AIConversation::mark_request_cancelled`). In the interrupt case there is no stream: the turn is mid-tool-call, so the conversation is moved to `Cancelled` by the controller's `FinishedAction` handler (`controller.rs`, the "mixed results → Cancelled" branch) and by `stop_local_agent_conversation`'s direct `update_conversation_status(Cancelled)` — neither carries a reason. So the exchange is not a reliable place to look. **Proposal.** 1. `app/src/ai/agent/mod.rs`: add `CancellationReason::SharedSessionControl`. `conversation_outcome()` → `CancellationOutcome::Cancelled`; `Display` → `"shared session control action"`. (Only these two matches are exhaustive over the enum.) 2. `app/src/ai/agent/conversation.rs`: mirror the existing `status_error: Option<RenderableAIError>` pattern with `status_cancellation_reason: Option<CancellationReason>`, set by a new `update_status_with_cancellation_reason(status, reason, ...)` (cleared when the status is not `Cancelled`), exposed via `status_cancellation_reason()`; `BlocklistAIHistoryModel` gets the matching `update_conversation_status_with_cancellation_reason`. Persist it alongside `status_error` if that is persisted (check `conversation_yaml` / the persisted conversation state; a restart mid-interrupt is an edge case, not a blocker). 3. Plumb the reason: `TerminalView::stop_local_agent_conversation(conversation_id, reason, ctx)` takes the `CancellationReason` (local callers pass `ManuallyCancelled`, the new `handle_shared_session_cancel_action` passes `SharedSessionControl`) and forwards it to `cancel_conversation_progress`, to its direct `Cancelled` status write, and — via `BlocklistAIActionEvent::FinishedAction { cancellation_reason }` — the controller's `FinishedAction` handler records it when it writes `Cancelled`. `mark_request_cancelled` already has the reason and should record it too, so the stream-cancel path is covered for free. 4. `local_agent_task_sync_model.rs`: in `map_conversation_status`, `ConversationStatus::Cancelled` matches on `conversation.status_cancellation_reason()`: `Some(SharedSessionControl)` → `(AgentTaskState::Succeeded, Some(TaskStatusUpdate::message("Turn interrupted")))`; anything else keeps `(Cancelled, "Cancelled by user")`. The reason is available where the update is computed because `on_conversation_status_updated` runs off `BlocklistAIHistoryEvent::UpdatedConversationStatus` and reads the conversation from the history model synchronously, after the status (and reason) have been written. 5. Tests: `local_agent_task_sync_model_tests.rs` — `map_conversation_status` with `Cancelled` + `SharedSessionControl` → `Succeeded`/"Turn interrupted", and `Cancelled` + `ManuallyCancelled`/`None` → unchanged; `view_tests.rs` — `handle_shared_session_cancel_action` records `SharedSessionControl` on the conversation while a local Ctrl-C stop records `ManuallyCancelled`. Caveat to confirm with the server side: reporting `Succeeded` for an interrupted turn means the run shows as succeeded in lists until the next turn; if a distinct state is preferred the mapping in step 4 is the single place to change. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Stopping a shared Agent Mode conversation from a viewer or via conversation steering now interrupts the agent's running command instead of letting it run to completion. --- Conversation: https://staging.warp.dev/conversation/8eaf5a4f-d303-465a-8498-f6267e0a0347 Run: https://platform.staging.warp.dev/runs/01a084d0-cfc8-7b67-b960-97c4e2622c47

Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 6.0.0 to 7.0.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/actions/upload-artifact/releases">actions/upload-artifact's releases</a>.</em></p> <blockquote> <h2>v7.0.1</h2> <h2>What's Changed</h2> <ul> <li>Update the readme with direct upload details by <a href="https://github.com/danwkennedy"><code>@danwkennedy</code></a> in <a href="https://redirect.github.com/actions/upload-artifact/pull/795">actions/upload-artifact#795</a></li> <li>Readme: bump all the example versions to v7 by <a href="https://github.com/danwkennedy"><code>@danwkennedy</code></a> in <a href="https://redirect.github.com/actions/upload-artifact/pull/796">actions/upload-artifact#796</a></li> <li>Include changes in typespec/ts-http-runtime 0.3.5 by <a href="https://github.com/yacaovsnc"><code>@yacaovsnc</code></a> in <a href="https://redirect.github.com/actions/upload-artifact/pull/797">actions/upload-artifact#797</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/upload-artifact/compare/v7...v7.0.1">https://github.com/actions/upload-artifact/compare/v7...v7.0.1</a></p> <h2>v7.0.0</h2> <h2>v7 What's new</h2> <h3>Direct Uploads</h3> <p>Adds support for uploading single files directly (unzipped). Callers can set the new <code>archive</code> parameter to <code>false</code> to skip zipping the file during upload. Right now, we only support single files. The action will fail if the glob passed resolves to multiple files. The <code>name</code> parameter is also ignored with this setting. Instead, the name of the artifact will be the name of the uploaded file.</p> <h3>ESM</h3> <p>To support new versions of the <code>@actions/*</code> packages, we've upgraded the package to ESM.</p> <h2>What's Changed</h2> <ul> <li>Add proxy integration test by <a href="https://github.com/Link"><code>@Link</code></a>- in <a href="https://redirect.github.com/actions/upload-artifact/pull/754">actions/upload-artifact#754</a></li> <li>Upgrade the module to ESM and bump dependencies by <a href="https://github.com/danwkennedy"><code>@danwkennedy</code></a> in <a href="https://redirect.github.com/actions/upload-artifact/pull/762">actions/upload-artifact#762</a></li> <li>Support direct file uploads by <a href="https://github.com/danwkennedy"><code>@danwkennedy</code></a> in <a href="https://redirect.github.com/actions/upload-artifact/pull/764">actions/upload-artifact#764</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/Link"><code>@Link</code></a>- made their first contribution in <a href="https://redirect.github.com/actions/upload-artifact/pull/754">actions/upload-artifact#754</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/upload-artifact/compare/v6...v7.0.0">https://github.com/actions/upload-artifact/compare/v6...v7.0.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/actions/upload-artifact/commit/043fb46d1a93c77aae656e7c1c64a875d1fc6a0a"><code>043fb46</code></a> Merge pull request <a href="https://redirect.github.com/actions/upload-artifact/issues/797">#797</a> from actions/yacaovsnc/update-dependency</li> <li><a href="https://github.com/actions/upload-artifact/commit/634250c1388765ea7ed0f053e636f1f399000b94"><code>634250c</code></a> Include changes in typespec/ts-http-runtime 0.3.5</li> <li><a href="https://github.com/actions/upload-artifact/commit/e454baaac2be505c9450e11b8f3215c6fc023ce8"><code>e454baa</code></a> Readme: bump all the example versions to v7 (<a href="https://redirect.github.com/actions/upload-artifact/issues/796">#796</a>)</li> <li><a href="https://github.com/actions/upload-artifact/commit/74fad66b98a6d799dc004d3353ccd0e6f6b2530e"><code>74fad66</code></a> Update the readme with direct upload details (<a href="https://redirect.github.com/actions/upload-artifact/issues/795">#795</a>)</li> <li><a href="https://github.com/actions/upload-artifact/commit/bbbca2ddaa5d8feaa63e36b76fdaad77386f024f"><code>bbbca2d</code></a> Support direct file uploads (<a href="https://redirect.github.com/actions/upload-artifact/issues/764">#764</a>)</li> <li><a href="https://github.com/actions/upload-artifact/commit/589182c5a4cec8920b8c1bce3e2fab1c97a02296"><code>589182c</code></a> Upgrade the module to ESM and bump dependencies (<a href="https://redirect.github.com/actions/upload-artifact/issues/762">#762</a>)</li> <li><a href="https://github.com/actions/upload-artifact/commit/47309c993abb98030a35d55ef7ff34b7fa1074b5"><code>47309c9</code></a> Merge pull request <a href="https://redirect.github.com/actions/upload-artifact/issues/754">#754</a> from actions/Link-/add-proxy-integration-tests</li> <li><a href="https://github.com/actions/upload-artifact/commit/02a8460834e70dab0ce194c64360c59dc1475ef0"><code>02a8460</code></a> Add proxy integration test</li> <li>See full diff in <a href="https://github.com/actions/upload-artifact/compare/v6...043fb46d1a93c77aae656e7c1c64a875d1fc6a0a">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/upload-artifact&package-manager=github_actions&previous-version=6.0.0&new-version=7.0.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ev#15899) Bumps [azure/artifact-signing-action](https://github.com/azure/artifact-signing-action) from 1.2.0 to 2.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/azure/artifact-signing-action/releases">azure/artifact-signing-action's releases</a>.</em></p> <blockquote> <h2>v2.0.0</h2> <h2>What's Changed</h2> <ul> <li>refactor: migrate to new artifactsigning module by <a href="https://github.com/Jaxelr"><code>@Jaxelr</code></a> in <a href="https://redirect.github.com/Azure/artifact-signing-action/pull/133">Azure/artifact-signing-action#133</a></li> <li>docs: update README runtime version and action references by <a href="https://github.com/Jaxelr"><code>@Jaxelr</code></a> in <a href="https://redirect.github.com/Azure/artifact-signing-action/pull/139">Azure/artifact-signing-action#139</a></li> <li>refactor: upgrade packages to the latest versions by <a href="https://github.com/Jaxelr"><code>@Jaxelr</code></a> in <a href="https://redirect.github.com/Azure/artifact-signing-action/pull/135">Azure/artifact-signing-action#135</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/Azure/artifact-signing-action/compare/v1.2.0...v2.0.0">https://github.com/Azure/artifact-signing-action/compare/v1.2.0...v2.0.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/Azure/artifact-signing-action/commit/c7ab2a863ab5f9a846ddb8265964877ef296ee82"><code>c7ab2a8</code></a> refactor: upgrade packages to the latest versions (<a href="https://redirect.github.com/azure/artifact-signing-action/issues/135">#135</a>)</li> <li><a href="https://github.com/Azure/artifact-signing-action/commit/7664cea6ad50e2f1b08bf6d5b4a371527221231c"><code>7664cea</code></a> docs: update README runtime version and action references (<a href="https://redirect.github.com/azure/artifact-signing-action/issues/139">#139</a>)</li> <li><a href="https://github.com/Azure/artifact-signing-action/commit/64185d8ca9555a71ba666fc42fa2ed9461a9d583"><code>64185d8</code></a> refactor: migrate to new artifactsigning module (<a href="https://redirect.github.com/azure/artifact-signing-action/issues/133">#133</a>)</li> <li>See full diff in <a href="https://github.com/azure/artifact-signing-action/compare/b443cf8ea4124818d2ea9f043cba29fc3ec47b16...c7ab2a863ab5f9a846ddb8265964877ef296ee82">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=azure/artifact-signing-action&package-manager=github_actions&previous-version=1.2.0&new-version=2.0.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…5901) Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.85.13 to 2.86.8. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.86.8</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 48.0.1.</p> </li> <li> <p>Update <code>wasm-tools@latest</code> to 1.258.0.</p> </li> <li> <p>Update <code>oxfmt@latest</code> to 1.80.0.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.8.12.</p> </li> <li> <p>Update <code>kingfisher@latest</code> to 2.0.0.</p> </li> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.23.2.</p> </li> </ul> <h2>2.86.7</h2> <ul> <li> <p>Update <code>tombi@latest</code> to 1.4.1.</p> </li> <li> <p>Update <code>rafn@latest</code> to 0.1.5.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.22.0.</p> </li> </ul> <h2>2.86.6</h2> <ul> <li> <p>Update <code>dprint@latest</code> to 0.56.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.9.2.</p> </li> <li> <p>Update <code>biome@latest</code> to 2.5.10.</p> </li> </ul> <h2>2.86.5</h2> <ul> <li> <p>Update <code>zola@latest</code> to 0.23.4.</p> </li> <li> <p>Update <code>wasm-tools@latest</code> to 1.257.1.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.36.0.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.8.10.</p> </li> <li> <p>Update <code>cargo-dinghy@latest</code> to 0.8.6.</p> </li> <li> <p>Update <code>wasmtime@latest</code> to 48.0.0.</p> </li> </ul> <h2>2.86.4</h2> <ul> <li> <p>Update <code>oxfmt@latest</code> to 1.79.0.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.8.8.</p> </li> <li> <p>Update <code>martin@latest</code> to 1.14.0.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.56.0.</p> </li> <li> <p>Update <code>cargo-about@latest</code> to 0.9.2.</p> </li> </ul>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p>  <h2>[Unreleased]</h2> <h2>[2.87.9] - 2026-09-09</h2> <ul> <li> <p>Update <code>oxfmt@latest</code> to 1.82.0.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.9.2.</p> </li> <li> <p>Update <code>kache@latest</code> to 0.18.0.</p> </li> <li> <p>Update <code>d2@latest</code> to 0.9.0.</p> </li> <li> <p>Update <code>bpf-linker@latest</code> to 0.11.1.</p> </li> </ul> <h2>[2.87.8] - 2026-09-07</h2> <ul> <li> <p>Update <code>shfmt@latest</code> to 3.14.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.162.</p> </li> <li> <p>Update <code>protoc-gen-connect-openapi@latest</code> to 0.26.0.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.57.4.</p> </li> <li> <p>Update <code>cargo-llvm-cov@latest</code> to 0.9.1.</p> </li> <li> <p>Update <code>cargo-crap@latest</code> to 0.5.0.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.23.0.</p> </li> </ul> <h2>[2.87.7] - 2026-09-06</h2> <ul> <li> <p>Update <code>wasm-bindgen@latest</code> to 0.2.128.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.12.10.</p> </li> <li> <p>Update <code>tombi@latest</code> to 1.5.2.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.75.1.</p> </li> </ul>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/taiki-e/install-action/commit/fcf5432d9f50d67e37ee6e29bdb7a224ff67b4a7"><code>fcf5432</code></a> Release 2.86.8</li> <li><a href="https://github.com/taiki-e/install-action/commit/f62d9e4aee39b59d225de036323247d9aa3bcd5c"><code>f62d9e4</code></a> Update <code>wasmtime@latest</code> to 48.0.1</li> <li><a href="https://github.com/taiki-e/install-action/commit/f8e3d097225a92555fe656cd8c5ce7aebf885b60"><code>f8e3d09</code></a> Update <code>wasm-tools@latest</code> to 1.258.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/484825a046ee4cf51ff46e4525d0af31412a277b"><code>484825a</code></a> Update vacuum manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/6d0ad88d70ae4ea951105b5f44ac67d1b739df47"><code>6d0ad88</code></a> Update uv manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/36fe62475978dfc558afa1765e51c6d9975236e9"><code>36fe624</code></a> Update <code>oxfmt@latest</code> to 1.80.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/fbcb11bef5d276954dce6be82dd36d31890620a1"><code>fbcb11b</code></a> Update <code>mise@latest</code> to 2026.8.12</li> <li><a href="https://github.com/taiki-e/install-action/commit/6558a76193bdebc0fcf58fa1120f1c3976bb52b9"><code>6558a76</code></a> Update <code>kingfisher@latest</code> to 2.0.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/7d183c86d7fdea20b30442a1b39048f143f4dd65"><code>7d183c8</code></a> Update editorconfig-checker manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/12f8c84b95b5c8de1be2833276eeae67714b14da"><code>12f8c84</code></a> Update <code>cargo-zigbuild@latest</code> to 0.23.2</li> <li>Additional commits viewable in <a href="https://github.com/taiki-e/install-action/compare/82cd3e7658a6f96c86c0234aeeda1748937cb0a1...fcf5432d9f50d67e37ee6e29bdb7a224ff67b4a7">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=taiki-e/install-action&package-manager=github_actions&previous-version=2.85.13&new-version=2.86.8)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…v#15902) Bumps [slackapi/slack-github-action](https://github.com/slackapi/slack-github-action) from 3.0.5 to 4.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/slackapi/slack-github-action/releases">slackapi/slack-github-action's releases</a>.</em></p> <blockquote> <h2>Slack GitHub Action v4.0.0</h2> <h3>Major Changes</h3> <ul> <li> <p>b1974f0: build: parse yaml with more strict multiline indentation rules</p> <p>Internal dependencies of <a href="https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md#500---2026-06-20"><code>js-yaml@v5</code></a> make YAML parsing more strict and compliant with the YAML specification. Indentation is now required for values that span multiple lines against the base value.</p> <p>See the YAML <a href="https://yaml.org/spec/1.2.2/#63-line-prefixes">line prefixes</a> spec for the expected indentation rule:</p> <pre lang="diff"><code> channel: "C0123" text: "first line <ul> <li>second line"</li> </ul> <ul> <li>second line"<br /> </code></pre></li> </ul> </li> </ul> <h3>Patch Changes</h3> <ul> <li>654bb72: chore: provide global fetch proxied configurations with updates to web api and webhook packages</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/slackapi/slack-github-action/blob/main/CHANGELOG.md">slackapi/slack-github-action's changelog</a>.</em></p> <blockquote> <h1>slack-github-action</h1> <h2>4.0.0</h2> <h3>Major Changes</h3> <ul> <li> <p>b1974f0: build: parse yaml with more strict multiline indentation rules</p> <p>Internal dependencies of <a href="https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md#500---2026-06-20"><code>js-yaml@v5</code></a> make YAML parsing more strict and compliant with the YAML specification. Indentation is now required for values that span multiple lines against the base value.</p> <p>See the YAML <a href="https://yaml.org/spec/1.2.2/#63-line-prefixes">line prefixes</a> spec for the expected indentation rule:</p> <pre lang="diff"><code> channel: "C0123" text: "first line <ul> <li>second line"</li> </ul> <ul> <li>second line"<br /> </code></pre></li> </ul> </li> </ul> <h3>Patch Changes</h3> <ul> <li>654bb72: chore: provide global fetch proxied configurations with updates to web api and webhook packages</li> </ul> <h2>3.0.5</h2> <h3>Patch Changes</h3> <ul> <li>96fddbe: fix: revert multiline yaml parsing indentation change</li> </ul> <h2>3.0.4</h2> <h3>Patch Changes</h3> <ul> <li>fa03fe4: refactor: send webhooks with the <a href="https://docs.slack.dev/tools/node-slack-sdk/webhook"><code>@slack/webhook</code></a> package</li> </ul> <h2>3.0.3</h2> <h3>Patch Changes</h3> <ul> <li>66834e4: feat: add instrumentation to address error rates</li> </ul> <h2>3.0.2</h2> <h3>Patch Changes</h3> <ul> <li>79529d7: fix: resolve url.parse deprecation warning for webhook techniques</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/slackapi/slack-github-action/commit/dcb1066f776dd043e64d0e8ba94ca15cc7e1875d"><code>dcb1066</code></a> chore: release</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/53861e0291660faf57ba686eabf046d5a47fa304"><code>53861e0</code></a> chore: release (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/645">#645</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/b1974f0d29f2b6150fc5a376312d365bd75fdd9b"><code>b1974f0</code></a> build!: parse yaml with more strict multiline indentation rules (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/640">#640</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/947ed0677cba8e56cf374d88bfd2d8f72aa9100c"><code>947ed06</code></a> build(deps): bump undici from 7.28.0 to 8.7.0 (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/653">#653</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/03922a90c917c4d3d3b1c0f35984c2ac23955560"><code>03922a9</code></a> chore: track undici-types to the resolved undici version (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/652">#652</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/31d473e1d0da2837ee5149493a62a54103e5b45a"><code>31d473e</code></a> build(deps-dev): bump typescript from 6.0.3 to 7.0.2 (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/651">#651</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/3ca6997fb72e86b0babe7037ff2ca4a5908b6148"><code>3ca6997</code></a> build(deps-dev): bump sinon and <code>@types/sinon</code> (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/649">#649</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/26a5ad3c5af9cde63a5bb0667fc9e40accce2710"><code>26a5ad3</code></a> build(deps): bump actions/setup-node from 6.4.0 to 7.0.0 (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/647">#647</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/5092efb0558a5d075f0dd02279f332a116a461ef"><code>5092efb</code></a> build(deps-dev): bump <code>@biomejs/biome</code> from 2.5.3 to 2.5.4 (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/650">#650</a>)</li> <li><a href="https://github.com/slackapi/slack-github-action/commit/3548c3e9500515cd56aa64222b12088f5e6bd6fe"><code>3548c3e</code></a> build(deps): bump slackapi/slack-github-action from 3.0.3 to 3.0.5 (<a href="https://redirect.github.com/slackapi/slack-github-action/issues/646">#646</a>)</li> <li>Additional commits viewable in <a href="https://github.com/slackapi/slack-github-action/compare/0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc...dcb1066f776dd043e64d0e8ba94ca15cc7e1875d">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=slackapi/slack-github-action&package-manager=github_actions&previous-version=3.0.5&new-version=4.0.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…warpdotdev#15317) ## Description Clicking a subagent's chip in the web session viewer swapped that agent into view and quietly rewrote the address bar to the subagent's own URL. It used `replaceState`, so the run's URL wasn't just hidden — it was gone. Refreshing loaded the subagent on its own, browser Back couldn't get you home, and copying the link shared one subagent instead of the whole run. That also explains a second symptom. A link captured after the rewrite points at the subagent, so reopening it loads a session with no orchestration context: the chips along the top are missing, and entries that can't be resolved to an agent show up as "unknown agent" (APP-4853). **The fix:** while the viewer is showing a `/conversation/:id` or `/session/:id` route, a focused pane can no longer replace that URL. Both paths that could rewrite it — pane focus, and a subagent joining its live session — run through one function, so the guard lives there. Login and signup redirects pass `force_redirect` and still work as before. What this gives up for now: the address bar no longer follows your subagent selection, so a refresh returns to the run with nothing selected. ## What comes next This PR also checks in the agreed design for proper subagent links, under `specs/QUALITY-1764/`: - **Phase 1** — opening a subagent's link takes you to the top-level run with that agent selected, with `?view=standalone` to opt out and stay on the subagent. - **Phase 2** — the selection lives in the URL as `#child=<run-id>`, so a refresh restores it and Back/Forward walk through the agents you looked at. **For whoever builds Phase 2:** the guard added here blocks exactly the kind of URL write the anchor needs. Remove or invert it first — putting the anchor writer behind it means the fragment silently never appears. ## Linked Issue - Linear: [QUALITY-1764](https://linear.app/warpdotdev/issue/QUALITY-1764/web-session-viewer-rewrites-the-browser-url-to-the-childs) - Linear: [APP-4853](https://linear.app/warpdotdev/issue/APP-4853/subagent-chips-missing-and-unknown-agent-shown-when-opening-session) — same root cause, for sessions reopened from a rewritten link ## Testing Unit tests cover `resolve_browser_url`, the single function both rewrite paths go through: - keeps the run's URL when a subagent's pane asks to replace it - keeps it when the focused pane has no link of its own - leaves the URL alone outside the viewer, so the guard doesn't over-fire - still redirects when `force_redirect` is set, so login and signup are unaffected `cargo nextest run -p warp -E 'test(/^uri::/)'` — 73 passed. `cargo clippy -p warp --all-targets --tests -- -D warnings`, `cargo fmt --check`, and a `wasm32-unknown-unknown` `cargo check` are all clean. **Not verified in a browser.** Two attempts, both blocked at authentication. The second used the recipe suggested in review — `./script/wasm/run --features with_local_server,with_local_session_sharing_server` against a local `warp-server` and `session-sharing-server`, with a real parent/child pair created through the LLM mock and the session set to `public_access=VIEWER` plus `--share public:view`. Opening `/session/<uuid>` still rendered only "Oops! Sign In failed. Please try again later.", before and after refresh, with no guest option and no viewer content. A team-scoped session behaved identically, so even an explicit public-viewer ACL did not bypass local browser auth. So the address-bar and refresh behaviour is covered by the `resolve_browser_url` unit tests and call-graph tracing, not a live capture. If there is a local auth shim or dev credential path we missed, say so and we will capture the flow. - [ ] I have manually tested my changes locally with `./script/run`   ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Opening a subagent in the web session viewer no longer replaces the run's URL, so refreshing or sharing the link keeps you on the whole run instead of a single subagent. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

…#15913) ## Description Adds a `docker-registry` provider subcommand to `oz secret create`, so users can create a `DOCKER_REGISTRY`-type managed secret from the CLI: ``` oz secret create docker-registry <NAME> [--host HOST] [--username USER] [--password PASS] ``` Any omitted field is prompted for interactively; non-interactive invocations require all three. This gives customers with GitHub-synced (`file_managed`) Factories a way to create registry credentials today, since the web UI's only creation path for this secret type currently lives in a form that's inaccessible for those Factories (tracked separately in warp-server#17092, which fixes the web UI gap). The underlying `ManagedSecretValue::docker_registry` constructor, encryption, and `createManagedSecret` mutation support already existed; this PR only adds the CLI arg-parsing and prompt-reading layers, plus client-side host format validation (no scheme or path) mirroring the server-side check. ## Linked Issue No linked GitHub issue. This is a CLI-only follow-up to warp-server#17092. ## Testing - [x] Added unit tests for CLI arg parsing (`crates/warp_cli/src/secret_tests.rs`) and host validation (`app/src/ai/agent_sdk/secret_tests.rs`) - [x] `cargo check`, `cargo fmt --check`, and `cargo clippy --all-targets -- -D warnings` all pass for `warp_cli` and `warp` - [ ] Manual testing with `./script/run` (not applicable — this is a CLI-only change; verified via `cargo run --bin warp -- secret create docker-registry --help`) ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Added `oz secret create docker-registry` to create container registry credential secrets from the CLI. Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

## Description The bundled Factory validator skipped benchmark configuration because it did not traverse or classify `benchmarks/`. It now submits canonical suite and task YAML files, plus noncanonical benchmark `.yaml` and `.yml` paths, to warp-server for authoritative validation. README and `.yaml.disabled` files remain unrelated and are not uploaded. The Factory-files skill now lists benchmark resources and their server-published schemas. ## Linked Issue No issue was created for this small, confirmed validation gap. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — No linked issue. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — Not applicable to this non-rendered Python validator. ## Testing - `./script/format --check` - `python3 -m py_compile resources/bundled/skills/factory-files/scripts/validate_factory_files.py script/test_factory_files_skill.py` - `./script/test_factory_files_skill.py` - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` - [ ] I have manually tested my changes locally with `./script/run` — Not applicable to a non-rendered validator script. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode   CHANGELOG-NONE --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

## Description Prevents Linux stable fatal `index out of bounds: the len is 0 but the index is 0` in `CodeReviewView::handle_action`. A stale second `ConfirmDiscardFile` action now treats an empty single-file discard path as a no-op, while valid first confirmations keep the existing behavior. Addresses [Sentry WARP-CLIENT-BETA-STABLE-8AM7](https://warpdotdev.sentry.io/issues/WARP-CLIENT-BETA-STABLE-8AM7) ([production event](https://sentry.io/organizations/warpdotdev/issues/7721121113/events/214fd843cb614994a6c43920650bea36/)). ## Linked Issue - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Not applicable: the linked work item is Sentry fatal issue 7721121113. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. Not applicable: this state guard has no visual change, and computer-use verification was excluded. ## Testing - `cargo nextest run -p warp test_duplicate_single_file_discard_confirmation_is_ignored` — passed (1 passed, 6540 skipped). With the original indexing restored, this test failed with the reported empty-vector panic at `CodeReviewView::handle_action`. - `./script/format` — passed. - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` — passed. - `cargo clippy -p warp --all-targets --tests -- -D warnings` — passed. - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` — passed. - [ ] I have manually tested my changes locally with `./script/run`. Not run; the focused action-level regression test covers the stale confirmation state without booting the GUI. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Prevented a crash when confirming a file discard more than once in Code Review.   Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

…arpdotdev#15869) ## Description Cloud agent sandboxes silently overrode a customer's own `git config --global user.name/email` setup command, so commits kept using Warp's identity instead of the customer's. **Root cause**: `configure_repository_git_identity` unconditionally wrote a repo-*local* `user.name`/`user.email` right after cloning, before setup commands ran. Local config always beats `--global`, so a customer's later override never took effect. This per-repo stamp exists for a reason: mixed-forge sandboxes (e.g. GitHub + GitLab) need a different identity per repo, which a single `--global` value can't express. **Fix**: snapshot the process-wide identity once at bootstrap, before any clone or setup command runs. After setup commands finish, only apply Warp's forge-appropriate identity to a repo if its *effective* identity still matches that snapshot. If it differs, something already claimed it (a `--global` override, a per-repo local one, etc.), so it's left alone. This also correctly handles a mixed-forge sandbox where the customer wants one shared identity across every repo. ## Linked Issue - [ ] N/A — found and fixed while investigating a customer report of cloud agent commits authored with the wrong git identity. ## Testing - Added unit tests for `repository_identity_changed_since` and `configure_repository_git_identity_if_unset` using real temp git repos. - `environment` (43 tests) and `git_credentials` (25 tests) module suites pass; `cargo check`/`clippy -D warnings` clean for this diff. - Not tested end-to-end in a live sandbox (no production credentials available here) — the fix is scoped to small, independently-testable pure functions. - [ ] I have manually tested my changes locally with `./script/run` ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed cloud agent commits sometimes ignoring a customer's `git config --global user.name/email` setup command.   --------- Co-authored-by: Warp <agent@warp.dev>

## Description Dragging a Settings tab through a preview can orphan its hidden About page because About was the only Settings page created without structural parentage. This changes About to the same parented typed-action view path as the other Settings pages, without adding a Settings child-ID inventory or suppressing missing-view panics. ## Linked Issue [APP-5314](https://linear.app/warpdotdev/issue/APP-5314/crash-dragging-settings-tab-between-windows-panics-in) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Linear label state was not available in this run. - [x] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing - `./script/format` — completed. - `cargo check -p warp` — passed after the test removal. - `cargo build -p warp` — passed. - `cargo clippy -p warp --all-targets --tests -- --deny warnings` — passed. - No automated regression test is included; this uses the existing typed-action ownership path. - Full workspace all-features Clippy remains blocked by unrelated existing cfg/test errors in `ai::execution_profiles` and dead-code warnings under the combined feature set. - Linux GUI: Warp remained responsive and About rendered after a drag attempt. The Linux tab rail confined the drag preview and snapped it back, so the Windows detach/return/preview-close path could not be exercised visually. - [ ] I have manually tested my changes locally with `./script/run`. Tested the internal build with `cargo run --bin warp`; Linux could not detach the Settings tab. ### Screenshots / Videos   ### Computer-use video recordings [![Opening Settings as a tab on Account, attempting to drag/detach the Settings tab into a preview or second window, trying to return it and close any preview/second window, then navigating to About.](https://staging.warp.dev/api/v1/agent/artifacts/01a09212-5206-78ae-9d7e-316713de6454/download)](https://platform.staging.warp.dev/artifacts/01a09212-4e94-74c3-8ccc-75d11201119c) **Settings tab detach/transfer test in Warp on Linux**: Opening Settings as a tab on Account, attempting to drag/detach the Settings tab into a preview or second window, trying to return it and close any preview/second window, then navigating to About.   ### Computer-use screenshots ![Settings tab's About page rendered after the failed drag/detach attempt, showing the Warp logo, version placeholder "v#.##.###", and "Copyright 2026 Warp" text, with the second Warp window still open in the taskbar.](https://staging.warp.dev/api/v1/agent/artifacts/01a09211-b065-7cfd-9538-3cb01426b2d7/download) Settings tab's About page rendered after the failed drag/detach attempt, showing the Warp logo, version placeholder "v#.##.###", and "Copyright 2026 Warp" text, with the second Warp window still open in the taskbar.   ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed a crash after dragging a Settings tab between windows. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

## Description Bump `warp-command-signatures` to the merged revision that adds `du --time` completions. ## Linked Issue No linked Warp issue; this integrates warpdotdev/command-signatures#405. - [ ] 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 Not run per request; CI will validate the dependency bump. - [ ] I have manually tested my changes locally with `./script/run` ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

## Description Ages ago, we explored an extensibility architecture for Warp involving JS-based plugins, including a JS plugin-based completions system. We never fully built this out, and kept around a bunch of code for the day that we might resuscitate it. These days, agents see the various places where we run clippy and tests multiple times, covering both the v1 and v2 completions implementations, and follow this example, running extra sets of tests to ensure that their changes work properly. Given that we're not going to do any work near-term to get the plugin system working, and that we don't want agents to be spending more time validating changes than they need to, it's time for us to rip this all out.

## Description Routes `BlocklistAIHistoryModel` updates through each owning `TerminalView` instead of subscribing every `AIBlock` for its lifetime. This removes broad per-block fanout while preserving footer, todo, streaming, restoration, transfer, and reassignment behavior. `TerminalView` now targets the existing indexed block handles by event: the previous pane/conversation latest blocks for appends, the exact exchange for streaming, todo-bearing blocks in the affected conversation, and latest root blocks for usage updates. Usage routing walks ancestor conversations so descendant costs continue to refresh orchestrator rollups. Streaming output processing remains limited to blocks whose output was live at construction, so persistence-only replays for completed restored or forked blocks do not rerun completion side effects. Approved architecture: https://warpdev.slack.com/archives/C0BDQDW8V5E/p1789143109438909 ## Linked Issue - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. No linked GitHub issue; the requester approved the change in the Slack thread above. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). The requester explicitly declined computer-use and visual verification. ## Testing - `./script/format` and `./script/format --check` - `cargo clippy -p warp --all-targets --tests -- -D warnings` - `cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings` - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` - Focused `cargo nextest run -p warp` coverage for append, streaming, completed restored/fork replay, todo, descendant usage rollup, reassignment, and restored-pane transfer behavior - `./script/check_no_inline_test_modules` - `git diff --check` - [ ] I have manually tested my changes locally with `./script/run`. Not run because visual verification was explicitly declined. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

Fixes warpdotdev#13898 ## Why Saving a launch config from a window with grouped tabs and reopening it gives you flat tabs — the groups are gone. `impl From<WindowSnapshot> for WindowTemplate` reads `snapshot.tabs` and `snapshot.active_tab_index` and never looks at `snapshot.tab_groups`, and `WindowTemplate` had nowhere to put them. Worth noting because it narrows the fix: **this is a gap in one path, not a missing capability.** Session restore already round-trips groups end to end — `persistence/sqlite.rs` writes them (`:1012-1038`) and reads them back (`:2538-2703`), covered by `test_sqlite_round_trips_tab_groups`. So the data model was already there; only the launch-config projection ignored it. ## What changed **Schema** (`launch_config.rs`) — `WindowTemplate` gains `tab_groups: Vec<TabGroupTemplate>` and `TabTemplate` gains `group: Option<usize>`, an index into that list. ```yaml windows: - tabs: - layout: {cwd: /srv/api} group: 0 - layout: {cwd: /tmp} # ungrouped, no `group` key tab_groups: - name: backend color: blue ``` Both fields are `skip_serializing_if` + `default`, so **existing configs are unaffected** — a window with no groups serializes byte-for-byte as before. There is a test asserting neither key appears in that case. Runtime `TabGroupId`s are deliberately *not* serialized. They are UUIDs minted per session, a config can be opened repeatedly, and it can be opened into a workspace that already holds groups — reusing saved ids would collide. The index indirection sidesteps that. **Restore** (`workspace/view.rs`) — `open_launch_config_window` resolves each tab's membership first, then creates a group for every index that kept a member and assigns the tabs' `group_id`s through it. Groups no tab joins are never inserted, so hand-authored YAML cannot leave an empty, unreachable group in workspace state — the same posture as the save path, which already drops groups whose members were all unsaveable. This mirrors the session-restore path deliberately, including both feature gates: groups are only created under `FeatureFlag::GroupedTabs`, and `pinned` is only honored under `FeatureFlag::PinnedTabs`. Two shapes only hand-edited YAML can produce are normalized on the way in: - A group named on both sides of an ungrouped tab. `tab_bar_slots` collapses each *contiguous* run into one container, so interleaved membership would draw two containers sharing one id. `resolve_group_memberships` keeps the first run and returns later stragglers ungrouped; reordering the tabs would also restore the invariant, but silently moving tabs a config explicitly ordered seemed the more surprising of the two. - An out-of-range `group` index, which leaves that tab ungrouped rather than failing the window — same posture as session restore, which drops a tab's group reference when the group itself did not restore. ## The part that needed care The save path filters out tabs that cannot be represented (notebook panes) and **renumbers the survivors** via `num_valid_tabs`. So group membership cannot be derived from tab position — the snapshot index and the template index diverge exactly when a tab drops out. Membership is instead carried on each tab's own `group_id` and resolved against the surviving group list. Two consequences, both locked by tests: - A group whose only member failed to convert is **dropped**, rather than restored as an empty group the user can neither see nor remove. - When that happens, later groups shift down, and the remaining tabs' `group` indices shift with them. `test_config_from_snapshot_remaps_groups_around_unsaveable_tabs` is the one that guards this, and I checked it actually bites rather than trusting the green run: dropping the "keep only groups that still have a member" filter turns it red with ``` assertion `left == right` failed: empty group must be dropped left: 2 right: 1 ``` and restoring the filter returns the suite to 14 passed. ## Tests Three new tests in `launch_config_tests.rs`: - `test_config_from_snapshot_preserves_tab_groups` — name/color carried, membership correct, ungrouped tabs stay ungrouped - `test_config_from_snapshot_remaps_groups_around_unsaveable_tabs` — the re-indexing case above - `test_config_from_snapshot_omits_tab_groups_when_there_are_none` — backward compatibility of the serialized form The four existing `WindowTemplate` / `TabTemplate` literals in `crates/integration/src/test/launch_configs.rs` were updated for the new fields; no behavior change there. End-to-end coverage of the restore half lives in `test_launch_config_restores_tab_groups` (`crates/integration/src/test/launch_configs.rs`), which dispatches the real `root_view:open_launch_config` and asserts the restored window through a new `assert_tab_groups` helper. The helper numbers groups by first appearance in the tab list, so it pins down membership *and* identity — two tabs share an index only when they share a `TabGroupId` — then checks each group's restored name and color, and that the workspace holds exactly those groups and no memberless extras. I checked it bites rather than trusting the green run; asserting the pre-collapse membership fails on exactly the tab the guard covers: ``` Expected tab group memberships [Some(0), Some(0), None, Some(0), Some(1)], but there were [Some(0), Some(0), None, None, Some(1)] ``` ## Manual validation ![Restoring a launch config with tab groups](https://raw.githubusercontent.com/maxmilian/warp/pr-assets-13898/tab-groups-restore.gif) Local `./script/run` OSS build, opened via `warposs://launch/Tab%20Groups%20Demo` so the restore path runs exactly as it would from the launch config palette. The tab bar comes back as `[Backend | api worker] scratch stray [Frontend | web]`: both groups restore with their names and blue/green colors, each tab lands back in its saved group, and `stray` — which asked for `Backend` again after an ungrouped tab — comes back ungrouped rather than opening a second container sharing the same id. (The GIF is hosted on a branch in my fork because I have no way to attach media to a PR from the CLI; happy to re-upload it wherever you'd prefer.) `cargo fmt -- --check` is clean, `cargo check -p warp --all-targets` is clean, `cargo test -p warp --lib launch_config` is 18 passed / 0 failed, and the integration test above is 1 passed / 0 failed. An earlier comment of mine on this PR claimed `GroupedTabs` could not be enabled in a local build. That was wrong — `grouped_tabs` is in `default` in `app/Cargo.toml` and `enabled_features()` turns it on at startup — and the recording above is the correction. CHANGELOG-BUG-FIX: Add tab group persistence to (legacy) launch configs. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…arpdotdev#16162) ## Description Retain optional, server-owned Factory experiments in the cloud task snapshot and driver without interpreting keys or imposing a closed client schema. The existing-task bootstrap preserves the uninterpreted map in driver options and the driver, and emits exactly one `safe_info!` lifecycle line containing only presence and key count. Local runs emit no experiment line; unknown future values remain compatible across server/client versions. This is the driver half of REMOTE-3251 and implements the approved [spec PR #18098](warpdotdev/warp-server#18098). Land this PR before [server PR #18268](warpdotdev/warp-server#18268) so the driver accepts server-provided snapshots before they are emitted. ## Linked Issue - [REMOTE-3251](https://linear.app/warpdotdev/issue/REMOTE-3251/add-factoryyaml-experimental-flags-for-per-factory-server-and-agent) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Label not independently verified here; its implementation spec is approved. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). No UI change or visual verification applies. ## Testing - `cargo nextest run --manifest-path /workspace/warp/Cargo.toml -p cloud_object_models`: 41 passed. - `cargo nextest run -p warp -E 'test(ai::agent_sdk::)'`: 755 passed on the refreshed `master` base, including existing-task bootstrap, driver retention, and privacy-safe logging cases. - `cargo clippy --manifest-path /workspace/warp/Cargo.toml -p warp --all-targets --tests -- -D warnings`: passed. Earlier `cloud_object_models` package tests (41 passed) and Clippy also passed. - `./script/format` and `git diff --check`: passed on the refreshed branch. No manual GUI run; this change only affects headless task metadata transport and logging. CI for this ready-for-review PR is pending after the base merge. - [ ] I have manually tested my changes locally with `./script/run`. No GUI path changed; exercised with automated tests instead. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

…pdotdev#6004 (warpdotdev#16072) ## Root cause analysis I dug into this against the current source and found the mechanism. The short version: **the crash-recovery watcher process that Warp spawns on every Windows launch is not exempted from the single-instance startup-args forwarding, so it forwards a `new_window` URL back to the instance that spawned it.** ### The chain 1. On Windows, every GUI launch spawns a crash-recovery watcher child of `warp.exe` itself (`enable_crash_recovery` is on for Windows/Linux; with no `WGPU_BACKEND` override, `choose_crash_recovery_mechanism()` returns `DisableOpenGL`). See `app/src/crash_recovery.rs` — `spawn_recovery_process()` relaunches the current exe with `--parent-handle=... --crash-recovery-mechanism=...`, and the child just waits for the parent to die. 2. The watcher has no subcommand, so it parses as `LaunchMode::App` and runs the **full GUI startup path** — including `app_services::windows::pass_startup_args_to_existing_instance()` (`app/src/lib.rs`, runs *before* `CrashRecovery::new`). There is no `is_crash_recovery_process()` exemption there. 3. By the time the child runs that check, the parent already holds the `Local\Warp{channel}_SingleInstance` mutex (it created it during its own earlier check, before spawning the child). So the child concludes *"another instance is running, I'm a second launch"*. 4. Since the child has no URLs on its command line, the forwarding code fabricates one: `warp://action/new_window?path=<cwd>` (`app/src/app_services/windows/mod.rs`). The `cwd` here is inherited from the parent — i.e. the shortcut's *Start in* directory. **That's why the duplicate window opens in `~\AppData\Local\Programs\Warp`** — it's the install dir from the shortcut, which matches what's reported in this issue. 5. `Action::NewWindow` passes `window_id: None`, so `open_file()` unconditionally dispatches `root_view:open_new_from_path` — a brand-new window, never a tab in an existing one. ### Why it's timing-dependent (and why the first launch is fine) The parent spawns the watcher *before* its URI named-pipe server exists (the pipe is created much later, in `app_services::init` inside the run closure). So it's a race: - **Child connects before the pipe exists** → connect fails → the child falls into the "unknown forwarding error" branch and continues as the watcher. No extra window. (Most machines land here, which is why this isn't universal.) - **Child connects after the pipe is up** → forwarding succeeds → the parent opens a duplicate window, and the child exits. On a cold first launch the parent has extra work before the pipe comes up (creating the SQLite DB, running migrations, first-run setup), so the child normally loses the race — one window. On subsequent launches everything is warm, the parent reaches pipe creation sooner, and on a given machine the race resolves the same way every time — hence "always two windows". ### Why disabling session restore doesn't help `save_app` snapshots **all** live windows on window move/focus/resize/close callbacks, so once a duplicate exists it gets persisted and restored. But the forwarded `new_window` URL opens a window regardless of the restore setting, which matches the observation above that disabling *"Restore windows, tabs, and panes on startup"* doesn't make the duplicate go away. ## Proposed fix Exempt the crash-recovery watcher from startup-args forwarding (mirrors the existing `finish_update` exemption): ```diff // app/src/app_services/windows/mod.rs #[derive(Error, Debug)] #[cfg(feature = "release_bundle")] pub enum StartupArgsForwardingError { #[error("should not forward arguments after an auto-update")] IgnoredAfterAutoUpdate, + #[error("should not forward arguments from the crash recovery process")] + IgnoredForCrashRecoveryProcess, #[error("there is no other instance of Warp")] NoExistingInstance, #[error("failed to construct url")] ``` ```diff // app/src/app_services/windows/mod.rs pub fn pass_startup_args_to_existing_instance( args: &warp_cli::AppArgs, ) -> Result<(), StartupArgsForwardingError> { if args.finish_update { return Err(StartupArgsForwardingError::IgnoredAfterAutoUpdate); } + // The crash recovery watcher process is spawned by the main instance on + // every launch. It must not forward a new-window URL back to its parent, + // which would make the parent open a duplicate window. + if crate::crash_recovery::is_crash_recovery_process(args) { + return Err(StartupArgsForwardingError::IgnoredForCrashRecoveryProcess); + } if SingleInstanceManager::is_sole_running_instance()? { return Err(StartupArgsForwardingError::NoExistingInstance); } ``` ```diff // app/src/lib.rs (Windows forwarding match) // If we just finished an auto-update, we should continue running. Err(app_services::windows::StartupArgsForwardingError::IgnoredAfterAutoUpdate) => {} + // The crash recovery watcher process should continue running so it + // can wait on its parent; it must not forward args to it. + Err(app_services::windows::StartupArgsForwardingError::IgnoredForCrashRecoveryProcess) => {} ``` The Linux/D-Bus forwarding path (`app/src/app_services/linux/mod.rs`) has the identical hole — it also fabricates a `new_window` URL when no URLs are passed — so it needs the same exemption (wrapped in `cfg_if!` there, since FreeBSD compiles that module without `enable_crash_recovery`). With this patch built from source (stable channel, `release_bundle`), the duplicate window no longer appears on a machine that reproduced it on every launch (Windows 10 22H2, v0.2026.09.09.08.26.stable_02 codebase). Fixes warpdotdev#6004 ---------

## Description Prevent concurrent requests using the same `BaseClient` from launching overlapping workload-token refreshes. These can race during NSC's first-run config initialization and fail otherwise valid startup requests. ### What went wrong In the linked staging run, the worker started successfully, but the client could not report `worker_container_ready`. Obtaining the workload token for that request failed locally: `nsc` exited with `While parsing config: unexpected end of JSON input`. The readiness request therefore never reached the server. - https://staging.warp.dev/debug/ambient-agent/01a0e73e-7375-7cc3-8b0e-093f6319b83f - https://staging.warp.dev/debug/ambient-agent/01a0d9dd-cb69-75c3-8bff-1fc39b03a1fb Workspace polling and cloud-object fetching failed with the same error in the same millisecond. Authentication recovered roughly three seconds later, and the run eventually succeeded. However, the missing readiness event left the timeline at `oz_run_claimed`. The server rejected the later `shared_session_started` and `agent_started` events because readiness must precede them. The resulting timeline showed only created, claimed, and done. ### The race There are two interacting pieces: 1. **Concurrent cache misses in our client.** The existing mutex protected reading and writing the cached token, but was released before awaiting token issuance. At startup, multiple requests could all observe an empty cache and independently run `nsc auth issue-id-token`. 2. **Non-atomic config initialization in NSC.** On first use, NSC creates its config file, normally `~/.config/ns/config.json`, then writes `{}` to it in a separate operation. It subsequently reads that file as JSON. This permits the following interleaving: - Process A creates the config file. It exists but is still empty. - Process B sees the file and skips initialization. - Process B reads the empty file and fails JSON parsing before issuing a token. - Process A finishes writing the file, so later invocations can succeed. NSC uses exclusive creation, which prevents two processes from creating the file, but does not prevent another process from reading it before the initial write completes. See the [upstream config initialization and read path](https://github.com/namespacelabs/foundation/blob/a836d21c1b1f84414cd46f6d217663fc9521fcaf/internal/cli/fncobra/main.go#L335-L390). The local config-parsing failure is confirmed by the run logs. This first-use race is the likely explanation, not a proven reconstruction: we did not capture the config contents at failure time or match the deployed NSC version. ### What this changes Add an async refresh mutex to `BaseClient`. On a cache miss, a caller acquires that mutex and checks the cache again before issuing a token. The mutex remains held through issuance and cache storage, so waiting callers reuse a sufficiently long-lived token instead of launching another NSC process. Valid cached-token reads retain their fast path and do not wait on the refresh mutex. Failed refreshes release the mutex so another caller can proceed. No synchronous cache mutex is held across an await. The lock coordinates callers sharing a `BaseClient`; it does not serialize direct token-issuance calls outside that client or other processes. This PR adds no retries and leaves readiness-event delivery unchanged. ## Linked Issue [Investigated staging run](https://staging.warp.dev/debug/ambient-agent/01a0d9dd-cb69-75c3-8bff-1fc39b03a1fb) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — No issue linked; this follows the run investigation. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — Not applicable to this concurrency fix. ## Testing Completed before PR preparation: - `cargo nextest run -p warp_server_client`: all 57 tests passed. - `cargo check -p warp_server_client`: passed. - `cargo clippy -p warp_server_client --all-targets --tests -- -D warnings`: passed. - Crate-scoped formatting with repository settings and `git diff --check`: passed. Regression tests cover concurrent cold/expired-cache requests, release of waiting callers after failure, and cached reads during refresh. No additional validation was run when creating the PR, as requested. - [ ] I have manually tested my changes locally with `./script/run` — Not run; validation was scoped to the client crate. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode [Agent conversation](https://staging.warp.dev/conversation/be5216ef-8abd-4a01-b1da-5667b0540172) ## Changelog Entries for Stable CHANGELOG-OZ: Improved cloud agent startup reliability by preventing overlapping workload-token refreshes within the shared API client. Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

…6213) ## Description When Warp and native shell completions are both enabled, an empty bundled-spec result asks the shell, but an empty shell reply left Tab without a completion menu. This adds a final, file-path-only Warp fallback after both sources are empty. Nonempty bundled suggestions still take precedence over the shell, and nonempty native suggestions still take precedence over file paths. The native handoff also cancels active session commands if the completion request is aborted. It does not change the Git or Go specs. ## Linked Issue Follow-up to [warpdotdev#16019](warpdotdev#16019) and [warpdotdev#16093](warpdotdev#16093); [reported in Slack](https://warpdev.slack.com/archives/C0BUDAYSD36/p1790787008678169). - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement` — not asserted for this follow-up. - [x] Where appropriate, screenshots or a short video of the implementation are included below. ## Testing - Added input-view regression tests for the empty combined-mode fallback and native priority. The fallback and phase-two cancellation tests each failed before their respective fixes and passed afterward; bundled-priority and stale-dispatch tests passed. - `CARGO_HOME=/workspace/.cargo CARGO_TARGET_DIR=/workspace/warp-build cargo nextest run --manifest-path /workspace/warp/Cargo.toml -p warp -E 'test(combined_completions_) | test(input_tab_does_not_ask_the_shell_when_bundled_specs_are_non_empty) | test(input_tab_asks_the_shell_once_when_bundled_specs_are_empty) | test(native_completions_after_empty_specs_bails_when_stale) | test(aborting_native_completions_after_empty_specs_cancels_session_commands)' -j 4` — 6 passed. - `cargo clippy -p warp --all-targets --tests -j 4 -- -D warnings` and `cargo build --bin warp -j 4` — passed with the writable Cargo home/target above. `./script/format` completed. - Linux GUI (`cargo run --bin warp`, both completion settings enabled): before the fix, `git apply <Tab>` showed Git flags while `go run -- <Tab>` showed no menu. After the fix, Git flags still won; `go run -- <Tab>` showed file and directory candidates, and an unknown command with `./app/src/` showed paths from that directory. The two reported commands take different parser paths. - A separate macOS 26/aarch64 verifier built commit `4803b2152`, passed three focused tests, and checked the running zsh GUI. That shell lacked zsh's completion setup (`_generic: none`), so neither the existing native-only path nor the combined path opened a menu. After `autoload -Uz compinit; compinit -u`, native-only `warptool ./` opened a menu; with both settings on, `git apply ~/` listed 10 home paths including a patch fixture, and `go run -- ` listed directory candidates. - [ ] I have manually tested my changes locally with `./script/run` — tested the same GUI binary with `cargo run --bin warp` instead. ### Screenshots / Videos  **Recordings (Linux)** - [Before: both settings and reported Tab flows](https://platform.staging.warp.dev/artifacts/01a0f393-8032-7f17-b79b-0cdeaafcc978) - [After: Git flags, Go file paths, and unknown-command file paths](https://platform.staging.warp.dev/artifacts/01a0f3ae-5fb5-7994-abd5-4626640faceb) - [After: exact `git apply ~/` home-directory completion](https://platform.staging.warp.dev/artifacts/01a0f3b6-8cb9-7be7-a829-d736bfe6940a) **Screenshots** - [`go run -- <Tab>` before: no menu](https://platform.staging.warp.dev/artifacts/01a0f393-5831-70c8-baa3-b91e83f0bb46) - [`go run -- <Tab>` after: file and directory menu](https://platform.staging.warp.dev/artifacts/01a0f3ad-db40-74dd-a9c8-d85c3cf364c7) - [`git apply <Tab>` after: Git flags](https://platform.staging.warp.dev/artifacts/01a0f3ad-421f-79bc-9189-62cb49f24683) - [`git apply ~/ <Tab>` after: `go/` Directory and `warp-completion-proof.patch` File](https://platform.staging.warp.dev/artifacts/01a0f3b6-4340-7b30-af5c-39f9f5162bb3) - [`warptool ./app/src/ <Tab>` after: file paths](https://platform.staging.warp.dev/artifacts/01a0f3ae-3bc0-71b7-9db8-a661fff9bdbf)  ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed missing file-path completions when bundled and native completions both return no suggestions. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

## Description Cloud agents start with the local AWS credential strategy, so team metadata initialization can load the task pod's runtime role before the configured Bedrock role is applied. The Bedrock OIDC refresh then reused those unexpired credentials and sent inference requests with the wrong role. This change clears loaded AWS credentials whenever `ApiKeyManager` changes refresh strategy. A local-chain callback checks that `LocalChain` is still active before publishing its result, so a late callback cannot overwrite task-scoped OIDC credentials. OIDC configuration and refresh completion remain owned by the agent driver. Investigation: https://staging.warp.dev/conversation/ec4c9302-d42c-4b6e-8307-935a00dd512a ## Linked Issue No linked issue. This fixes a customer-reported self-hosted Factory run failure. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — No linked issue. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — Non-UI change. ## Testing - `cargo nextest run --manifest-path /Users/iw/repos/warp/Cargo.toml -p ai -E 'test(aws_credentials_are_cleared_only_when_refresh_strategy_changes)'` — passed. - `cargo clippy --manifest-path /Users/iw/repos/warp/Cargo.toml -p ai -p warp --all-targets --tests -- -D warnings` — passed. - `./script/format` — completed. - End-to-end AWS validation was not run because it requires a self-hosted Kubernetes runner with distinct runtime and Bedrock IAM roles. - [ ] I have manually tested my changes locally with `./script/run` — Not applicable to the headless cloud-agent credential path. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed cloud agents using the runner's AWS credentials instead of the configured Bedrock role. Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

## Description  ## Linked Issue  - [ ] 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  - [ ] I have manually tested my changes locally with `./script/run` ### Screenshots / Videos  ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  --------- Co-authored-by: Warp <agent@warp.dev>

…#16165) ## Description WSL working-directory chips list files through the host without launching a guest subprocess; tab/path completion remains guest-backed. Paths beginning at the session home expand against that shell's home, not the host process's home. `warp_util::path` shares this expansion among the directory chip, `/open-file`, CDPATH resolution, and the tilde portion of SplitPath; `$HOME`, escaped literal tildes, cwd resolution, and suggestion display remain separately handled. Host-only and metadata-only callers remain unchanged. ## Linked Issue Refs warpdotdev#11741. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. (It currently carries `triaged` and `needs-info`.) - [ ] Where appropriate, screenshots or a short video of the implementation are included below. (Evidence is from the pre-refactor head; live final-head GUI verification was blocked.) ## Testing - Linux at current head: 3 session-home utility tests, 3 pre-existing chip sorting tests, and 4 completer/session-context tests passed (10 total). Targeted Clippy with `-D warnings` passed for `warp`; `./script/format` and `git diff --check` passed. - Windows at `100ec53812db9e4a36d2700776bbbaf1eef7bbe5`: 3 session-home utility tests, 19 completer path tests (2 ignored), and the `/open-file` WSL path test passed. Targeted Clippy for all three crates and the fully linked release build passed. - Prior live Ubuntu WSL1 chip listing/navigation/refresh proof below was captured at `8beb9c98b3a9c2497fbbb0392addeb73b9cc9290` and does not verify this final head. - Final-head live WSL1 GUI verification was blocked: after runner reset, the VM exposed only Microsoft Basic Display Adapter/OpenGL 1.1; stock Warp exited with `No usable wgpu adapter was found`. WSL2 was also blocked by unavailable nested virtualization (`HCS_E_HYPERV_NOT_INSTALLED`). No blocker media is presented as success proof. - The earlier draft-state CI aggregate failure reflected skipped required job parameters, not a code-test failure. The PR is now ready and full CI is starting. - [ ] I have manually tested my changes locally with `./script/run`. (Final-head GUI verification was blocked as above.) ### Screenshots / Videos The artifacts below show pre-refactor Ubuntu WSL1 behavior only. ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Avoid a WSL subprocess when listing the working directory from the prompt chip.   <details> <summary>Computer-use video recording</summary> [![Warp working-directory chip verification in Ubuntu WSL1: open, inspect, navigate, add a directory, and refetch.](https://staging.warp.dev/api/v1/agent/artifacts/01a0dadc-9c9a-7b66-9fc4-66f452cf42bf/download)](https://platform.staging.warp.dev/artifacts/01a0dadc-9a32-72f8-a2eb-9d607c04e243) **Ubuntu WSL1 working-directory chip verification**: Opens `~/warp-chip-proof`, verifies its directory/file listing, navigates into `alpha`, returns, adds `added-after-open-8beb9c9`, and confirms the refreshed listing persists across close/reopen. </details>   <details> <summary>Computer-use screenshots (2)</summary> ![Ubuntu WSL1 session in Warp showing WSL_DISTRO_NAME=Ubuntu, uname output, and the setup for ~/warp-chip-proof.](https://staging.warp.dev/api/v1/agent/artifacts/01a0dadb-390c-796a-b45c-047dd210f198/download) Ubuntu WSL1 session identity and fixture setup. ![The reopened ~/warp-chip-proof menu after creating added-after-open-8beb9c9, showing the refreshed directory and file listing.](https://staging.warp.dev/api/v1/agent/artifacts/01a0dadc-4146-7c24-9564-bdadfdebd8c7/download) Refreshed listing with `added-after-open-8beb9c9`, `alpha`, `beta`, `gamma`, `one.txt`, and `two.md`. </details>   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

…9eee32 to f0d9c3887740aee45f6153b24b3a6b815192ec16 (warpdotdev#15962) Bumps [Swatinem/rust-cache](https://github.com/swatinem/rust-cache) from e18b497796c12c097a38f9edb9d0641fb99eee32 to f0d9c3887740aee45f6153b24b3a6b815192ec16. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/Swatinem/rust-cache/blob/master/CHANGELOG.md">Swatinem/rust-cache's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <h2>2.9.2</h2> <ul> <li>Fix <code>credentials.toml</code> cleanup</li> <li>Improvements to cleanup, preserving more valid targets</li> <li>Improvements to <code>cargo install</code> handling</li> <li>Correctly sort/dedupe Rust versions</li> </ul> <h2>2.9.1</h2> <ul> <li>Fix regression in hash calculation</li> </ul> <h2>2.9.0</h2> <ul> <li>Update to <code>node24</code></li> <li>Support running from within a <code>nix</code> shell</li> <li>Consider all installed toolchains for cache key</li> <li>Use case-insensitive comparison to determine exact cache hit</li> </ul> <h2>2.8.2</h2> <ul> <li>Don't overwrite env for cargo-metadata call</li> </ul> <h2>2.8.1</h2> <ul> <li>Set empty <code>CARGO_ENCODED_RUSTFLAGS</code> when retrieving metadata</li> <li>Various dependency updates</li> </ul> <h2>2.8.0</h2> <ul> <li>Add support for <code>warpbuild</code> cache provider</li> <li>Add new <code>cache-workspace-crates</code> feature</li> </ul> <h2>2.7.8</h2> <ul> <li>Include CPU arch in the cache key</li> </ul> <h2>2.7.7</h2> <ul> <li>Also cache <code>cargo install</code> metadata</li> </ul> <h2>2.7.6</h2> <ul> <li>Allow opting out of caching $CARGO_HOME/bin</li> <li>Add runner OS in cache key</li> <li>Adds an option to do lookup-only of the cache</li> </ul> <h2>2.7.5</h2>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/Swatinem/rust-cache/commit/f0d9c3887740aee45f6153b24b3a6b815192ec16"><code>f0d9c38</code></a> Merge pull request <a href="https://redirect.github.com/swatinem/rust-cache/issues/380">#380</a> from Swatinem/dependabot/github_actions/actions-8ff58...</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/ccd9742ce3913201b7e871cc4b4f95ee3930f15b"><code>ccd9742</code></a> Bump the actions group with 2 updates</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/258712b0b7b1ddf8bddc9fc3b0faca682b2736c3"><code>258712b</code></a> fix: stop cleanup timestamp pruning after the first entry (<a href="https://redirect.github.com/swatinem/rust-cache/issues/377">#377</a>)</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/a45951ff880207c249adf57334cf2e9bd81d6e1e"><code>a45951f</code></a> Merge pull request <a href="https://redirect.github.com/swatinem/rust-cache/issues/373">#373</a> from Swatinem/dependabot/github_actions/actions-420be...</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/b882611972d6fc708ee5fad93358f413ec18d3a0"><code>b882611</code></a> Bump the actions group with 2 updates</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/6323deb102c322ba6fcbdcafc7e3dddab59af2b6"><code>6323deb</code></a> 2.9.2</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/b16e8d71b289c3b8fc03fc09764563df03712036"><code>b16e8d7</code></a> bump rollup and rebuild</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/3bf42ac996de475743278f3187c4fd89f23b8630"><code>3bf42ac</code></a> invert target/profile check in cleanup</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/6e5b278ead409e28cd5a784014d7ce55007a81d2"><code>6e5b278</code></a> correctly sort and dedupe Rust versions</li> <li><a href="https://github.com/Swatinem/rust-cache/commit/5adc05f6aaa7c92756cb2e2c9b7b3c1d0df9312b"><code>5adc05f</code></a> Bump the actions group across 1 directory with 3 updates (<a href="https://redirect.github.com/swatinem/rust-cache/issues/368">#368</a>)</li> <li>Additional commits viewable in <a href="https://github.com/swatinem/rust-cache/compare/e18b497796c12c097a38f9edb9d0641fb99eee32...f0d9c3887740aee45f6153b24b3a6b815192ec16">compare view</a></li> </ul> </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

) Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.86.8 to 2.87.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.87.0</h2> <ul> <li> <p>Support <code>kache</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1980">#1980</a>, thanks <a href="https://github.com/ChrisJr404"><code>@ChrisJr404</code></a>)</p> </li> <li> <p>Update <code>vacuum@latest</code> to 0.30.1.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.12.6.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.8.14.</p> </li> <li> <p>Update <code>editorconfig-checker@latest</code> to 3.11.2.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p>  <h2>[Unreleased]</h2> <h2>[2.87.11] - 2026-09-11</h2> <ul> <li> <p>Update <code>biome@latest</code> to 2.5.13.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.12.12.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.9.4.</p> </li> <li> <p>Update <code>kache@latest</code> to 0.19.0.</p> </li> </ul> <h2>[2.87.10] - 2026-09-10</h2> <ul> <li> <p>Update <code>zizmor@latest</code> to 1.30.1.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.12.11.</p> </li> <li> <p>Update <code>tombi@latest</code> to 1.5.4.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.164.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.9.3.</p> </li> <li> <p>Update <code>kingfisher@latest</code> to 2.2.0.</p> </li> </ul> <h2>[2.87.9] - 2026-09-09</h2> <ul> <li> <p>Update <code>oxfmt@latest</code> to 1.82.0.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.9.2.</p> </li> <li> <p>Update <code>kache@latest</code> to 0.18.0.</p> </li> <li> <p>Update <code>d2@latest</code> to 0.9.0.</p> </li> <li> <p>Update <code>bpf-linker@latest</code> to 0.11.1.</p> </li> </ul> <h2>[2.87.8] - 2026-09-07</h2>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/taiki-e/install-action/commit/37f7c5781271959fb65b6b35224e28652ff2b63d"><code>37f7c57</code></a> Release 2.87.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/fbf0dcd9d80d4930b5f271621fb87fca0f73cfc2"><code>fbf0dcd</code></a> Update changelog</li> <li><a href="https://github.com/taiki-e/install-action/commit/50af1ff0cc4404238f88dceaa52528a71eb71709"><code>50af1ff</code></a> Update kache manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/2897ba766bf8111039cc99ab6189bd55c024c843"><code>2897ba7</code></a> Support kache (<a href="https://redirect.github.com/taiki-e/install-action/issues/1980">#1980</a>)</li> <li><a href="https://github.com/taiki-e/install-action/commit/2abde849970ba6115125a08a3eaf145987ad7f87"><code>2abde84</code></a> Update <code>vacuum@latest</code> to 0.30.1</li> <li><a href="https://github.com/taiki-e/install-action/commit/b3b03e2942ace9b3c653b356a7827252ea860679"><code>b3b03e2</code></a> Update <code>uv@latest</code> to 0.12.6</li> <li><a href="https://github.com/taiki-e/install-action/commit/b372d10cdd0ee384b7ee53070a4c884f3a1211d1"><code>b372d10</code></a> Update prek manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/25ec8191aca7d307d8ab1cef97a5e2a48cada3a9"><code>25ec819</code></a> Update <code>mise@latest</code> to 2026.8.14</li> <li><a href="https://github.com/taiki-e/install-action/commit/db8b4348ed02e1607273ae9c2e831b639f17baa0"><code>db8b434</code></a> Update <code>editorconfig-checker@latest</code> to 3.11.2</li> <li><a href="https://github.com/taiki-e/install-action/commit/c5c3eaab597175a4b9bd85a04ebd2e1562a35466"><code>c5c3eaa</code></a> Update cargo-zigbuild manifest</li> <li>Additional commits viewable in <a href="https://github.com/taiki-e/install-action/compare/fcf5432d9f50d67e37ee6e29bdb7a224ff67b4a7...37f7c5781271959fb65b6b35224e28652ff2b63d">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=taiki-e/install-action&package-manager=github_actions&previous-version=2.86.8&new-version=2.87.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

## Description Explicit prompt submissions now bypass cached INPROGRESS deduplication for Claude Code and plugin-backed Codex. A harness can call finish-task before its stop hook fires, leaving the server completed while the client cache still records INPROGRESS. A follow-up in that interval must report progress again rather than trust the cache. Forced updates retain their boundaries through the serialized queue, including behind in-flight requests. Other status updates and conversation-token deduplication keep their existing behavior. No server or plugin changes are required. This addresses suppressed progress reporting only. The original turn's late stop can still close a newer follow-up; turn ordering remains separate work. Codex's legacy OSC 9 fallback is unchanged because it emits no prompt-start event. ## Linked Issue Investigated from [staging run 01a0f2e7-b6d5-7579-bfd2-f7a6a071d7d9](https://staging.warp.dev/debug/ambient-agent/01a0f2e7-b6d5-7579-bfd2-f7a6a071d7d9). - [ ] The linked issue is labeled ready-to-spec or ready-to-implement. No tracked issue is linked; the run above is the incident reference. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. No visual capture; this changes lifecycle reporting. ## Testing The original issue isn't easily reproducible due to timing, but tested locally with e2e tests a few times and tests passed on the hot follow up ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode ## Changelog Entries for Stable CHANGELOG-OZ: Claude Code and Codex follow-ups now report resumed activity even when the client retains a stale in-progress state. ## Agent artifacts [Investigation and implementation conversation](https://staging.warp.dev/conversation/3746e1d6-6945-41b2-b7a1-3f7ca1c96519) Co-Authored-By: Warp <agent@warp.dev> Co-authored-by: Warp <agent@warp.dev>

## Description Update the GraphQL codegen tooling's `brace-expansion` resolution to a patched 2.1.x release. The locked 2.1.2 version is affected by [CVE-2026-102277 / GHSA-q2hr-2g5m-vwhr](GHSA-q2hr-2g5m-vwhr); the lockfile now selects 2.1.7. This only changes development dependencies and leaves generated schema and runtime code untouched. ## Linked Issue [Dependabot alert 39](https://github.com/warpdotdev/warp/security/dependabot/39). - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Dependabot alerts are not GitHub issues. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. No rendered UI changed. ## Testing - `yarn --cwd crates/warp_graphql_schema install --frozen-lockfile --ignore-scripts --non-interactive --no-progress` passed. - `yarn --cwd crates/warp_graphql_schema run generate --help` loaded the codegen CLI without writing generated files. - `yarn --cwd crates/warp_graphql_schema audit --json --level moderate` reported zero advisories across 436 dependencies. - Asserted installed `brace-expansion` is 2.1.7; `git diff --check` passed. - [ ] I have manually tested my changes locally with `./script/run`. The desktop app does not exercise this development-only Yarn dependency. ## Agent Mode - [ ] Warp Agent Mode - This PR was created by a Factory run, not Warp Agent Mode. CHANGELOG-NONE   Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>

## Description Cloud agents on Windows runners can't clone private or internal repos, because git never sees the GitHub credential the client writes. The client writes `~/.git-credentials` under `dirs::home_dir()`. On Windows that is the profile of the account the process runs as, which is `C:\Windows\System32\config\systemprofile` when the agent runs as SYSTEM. But `git config --global` and git's `store` helper follow the environment, so they use `USERPROFILE` (`C:\Users\runneradmin`). Git finds no file and fails with `could not read Username … terminal prompts disabled`, because the Windows entrypoint sets `GIT_TERMINAL_PROMPT=0`. Public repos still clone, which is why this went unnoticed. On Windows, `home_dir()` in `git_credentials.rs` now resolves home the way git does: `HOME`, then `HOMEDRIVE` plus `HOMEPATH` if that directory exists, then `USERPROFILE`. It falls back to `dirs::home_dir()`. Other platforms are unchanged. The `gh`, `glab` and Azure files go through the same helper, so they move with the credential file. I chose to align the home directory instead of pinning `credential.helper` to `store --file=<path>`. Pinning would fix only git and would change a git setting that customer setup commands may already override. This is one of two Windows failures. warpdotdev#16234 fixes the other one, the factory-definition clone under PowerShell. The two are independent, but a Factory agent that clones a private repo on Windows needs both. Not covered here: `gh` reads its config from `%AppData%\GitHub CLI` on Windows, not `~/.config/gh`. This change puts the `gh` file in the right profile, but still not at a path `gh` reads. ## Linked Issue No linked issue. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. There's no issue to label. - [ ] Screenshots or a video are included. This isn't a user-visible change. ## Testing I added a table-driven unit test for the resolver. It covers the order of `HOME`, `HOMEDRIVE` plus `HOMEPATH`, and `USERPROFILE`, an empty `HOME`, a missing `HOMEDRIVE` plus `HOMEPATH` directory, and nothing set. It runs on any OS because the resolver takes the environment as a closure. - `cargo nextest run -p warp --lib git_credentials`: 33 passed. - `cargo clippy -p warp --all-targets --tests -- -D warnings`: clean. - `./script/format` ran last and changed only the two files in this PR. Before this change, a diagnostic run on a prod Windows runner showed `.git-credentials` (71 bytes) under `C:\Windows\System32\config\systemprofile` and `.gitconfig` under `C:\Users\runneradmin`. `git ls-remote` on an internal repo exited 128. I haven't run this branch on a Windows runner. It reaches runners only after a client release and a rebuilt Windows agent image. Please check one private-repo clone on a Windows run once that ships. - [ ] I have manually tested my changes locally with `./script/run`. I didn't launch the app, because this code only runs in cloud agent sandboxes. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed cloud agents on Windows runners failing to clone private repositories. Co-authored-by: Warp <agent@warp.dev>

…arpdotdev#16234) ## Description Warp-managed Factory runs on a Windows runner fail during environment setup. The client prepends `git clone "$WARP_FACTORY_REPO_CLONE_URL" "$WARP_FACTORY_REPO_DIR"` to the setup commands. Windows sessions run PowerShell, where a bare `$NAME` is an unset PowerShell variable. Both arguments expand to empty strings, and git exits 128 with `fatal: repository '' does not exist`. This change builds the command per shell: `$env:NAME` for PowerShell, and `$NAME` for Bash, Zsh and Fish. The call site reads the session's shell type after terminal bootstrap. It falls back to Bash if the type is unknown, like the other session-shell lookups in `environment.rs`. I kept the variable-reference approach instead of inlining the URL. The URL carries credentials, and expanding it in the shell keeps it out of command text and logs. Not covered here: - An environment that already stores its own copy of the old command is still left alone, because detection matches on the variable name. On Windows that stored copy keeps the bash syntax and still fails. - `export CI=true`, `unset CI` and the `test -d` directory probe are still POSIX-only. The first two have unchecked exit codes, so they're harmless. The `test -d` behavior in PowerShell is untested. ## Linked Issue There is no linked GitHub issue, so the first box stays unticked. This isn't a UI change, so there are no screenshots. - [ ] 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 I added a unit test that checks the generated command for every shell type, and updated the existing factory clone tests for the new argument. - `cargo nextest run -p warp factory_clone`: 5 passed. - `cargo clippy -p warp --all-targets --tests -- -D warnings`: clean. - `./script/format` ran last and changed only the three files in this PR. - I checked the shell behavior by hand in PowerShell 7.6.4 on macOS. With both variables set, `"$WARP_FACTORY_REPO_CLONE_URL"` is empty and git fails as above. `"$env:WARP_FACTORY_REPO_CLONE_URL"` holds the URL. I haven't run this on a Windows runner. The fix reaches Windows runners only after a client release and a rebuilt Windows agent image, so please check a Windows run once that ships. - [ ] I have manually tested my changes locally with `./script/run`. I didn't launch the app. The manual check was the PowerShell behavior above. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode Conversation: https://staging.warp.dev/conversation/bc67f2e9-d0f9-4d0c-b35a-5597b8f727fc CHANGELOG-BUG-FIX: Fixed Warp-managed Factory agents failing during environment setup on Windows runners. Co-authored-by: Warp <agent@warp.dev>

## Description Adds first-class Kiro CLI recognition so `kiro-cli` and `kiro` sessions get Warp's coding-agent toolbar and rich input without custom command patterns. Includes the official ghost logomark, Kiro purple, settings identity, and telemetry. Removes the enum-level `CLIAgent` doc comment as requested. Kiro has no Warp notification plugin or foreign skill-provider integration here. `kiro` is recognized by name as requested, even where a user configures it to open the IDE. The logo is adapted from https://kiro.dev/icon.svg; `!` shell mode follows Kiro's documented chat behavior. ## Linked Issue warpdotdev#9066 - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — Independent implementation requested; issue metadata left unchanged. - [x] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing - Passed Linux GUI build: `cargo build -p warp --bin warp`. - Passed targeted production lint: `cargo clippy -p warp --bin warp -- -D warnings`. - Applied `./script/format`. - No specs, new tests, or test-suite runs, per requester. - Real rendered Linux x86_64 verification with official Kiro CLI 2.27.0: visible ghost branding, native `kiro-cli` and `kiro-cli chat` recognition, scrollable settings selector, rich-input draft persistence, file explorer, empty changes panel, and exit-to-shell reset. - Kiro login requires credentials, so authenticated prompt acceptance and multiline delivery remain unverified. macOS/Windows were not exercised. Compound shell commands retain the existing first-command-only detection limitation. Additional `kiro` prefix build/lint passed; vendor launcher routing is not verified because the Linux CLI install does not provide it. - Current CI failure is draft aggregate gating: `Job params had unexpected status skipped (expected: success)`, not a source-check failure. - [ ] I have manually tested my changes locally with `./script/run` — Used the built internal `warp` binary directly for the rendered checks above. ### Screenshots / Videos  _Video_: [Real Linux Warp + official Kiro CLI: branding, settings selector, rich input and exit](https://platform.staging.warp.dev/artifacts/01a0f9d8-0286-7d32-8376-6f61651a350f)  ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-IMPROVEMENT: Added Kiro CLI support to Warp's third-party coding-agent toolbar and rich input. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

## Description Upgrade rmcp and bound MCP tool calls and environment setup so unresolved operations cannot consume the full sandbox lifetime. The investigation found missing MCP results after broken response streams and unfinished setup iterations. - Upgrade `rmcp` from **2.2.0 to 3.5.0**, picking up upstream request-scoped error propagation when an SSE response terminates without a final result after supported recovery. The fix shipped in the 3.0 release line via [rust-sdk#1000](modelcontextprotocol/rust-sdk#1000); no dependency fork is needed. Adapt OAuth metadata discovery, authorization requests, and client configuration to the 3.5 APIs. - Native MCP tool calls have a 30-minute total connection/dispatch/response budget, plus at most five seconds for best-effort cancellation. Timeout errors distinguish undispatched calls from unknown remote outcomes. - Do not automatically replay tools after ambiguous `TransportClosed` failures. Warp resource-read retries remain unchanged; tests verify valid SSE resumption still succeeds. - Each configured environment setup command has a 30-minute budget. Directory reset has a separate 30-second budget. Failures identify the command index and unconditionally redact known secrets. - Setup timeouts skip further terminal cleanup commands and live failure retention, while preserving postmortem session history. Add payload-free lifecycle diagnostics. The MCP limit also applies to local native-agent sessions. These fixed limits can interrupt legitimate longer operations. Cancellation is best-effort and does not prove that the remote tool stopped. Terminated response streams can fail without waiting for the 30-minute logical deadline. That deadline remains a safety net for calls that stay pending, including stalled connection or dispatch. `wait_for_events` and parent orchestration behavior are unchanged. <img width="892" height="592" alt="Screenshot 2026-09-30 at 4 33 07 PM" src="https://github.com/user-attachments/assets/4bd1def7-290a-4338-9865-0ee93d182aaa" /> ## Review guide Start with `Cargo.toml` and the 3.5 compatibility changes in `crates/mcp/src/oauth.rs` and `runtime.rs`. Then review `tool_call.rs` for the total deadline and bounded cancellation, followed by the setup timeout/teardown paths in `driver/environment.rs` and `driver.rs`. Focus on prompt EOF failure versus deadline fallback, valid resumption without tool replay, command redaction, and avoiding renewed waits during cleanup. Companion server diagnostics: warpdotdev/warp-server#18729 ## Linked Issue - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement` — no separate issue was created; investigation linked below. - [ ] Screenshots or a short video are included where appropriate — no visual/UI changes. ## Testing Manually tested setup command timeout <img width="448" height="216" alt="Screenshot 2026-09-30 at 5 11 38 PM" src="https://github.com/user-attachments/assets/164123b5-61ff-4a67-b3a3-d64d8f91fd01" /> ### Validation during the rmcp upgrade - `cargo nextest run -p mcp` passed: **40 tests**, including OAuth, deadline, EOF and resumption coverage. - `cargo check -p mcp --tests` and `cargo check -p warp --tests` passed. - `cargo clippy -p mcp --all-targets --tests -- -D warnings` passed. - The MCP crate was formatted with repository settings; `git diff --check` passed. - A standalone HTTP reproducer confirmed that empty SSE and progress-then-EOF responses leave calls pending in rmcp 2.2.0. The same cases return `TransportClosed` in released 3.0.0 and current upstream; successful-result controls pass in all three. ### Earlier deadline validation Recorded before the dependency upgrade: - 107 focused tests passed: `cargo nextest run --locked --lib --no-fail-fast -p warp -p mcp -E 'package(mcp) | test(setup_) | test(shell_exit_) | test(extend_shared_session_retention)'`. - `cargo check --locked -p warp --lib --tests` passed. - `cargo clippy --locked -p warp -p mcp --lib --tests -- -D warnings` passed. - Changed Rust files were formatted with repository settings; `git diff --check` passed. Coverage includes empty/truncated SSE responses failing with the logical deadline disabled, successful SSE results followed by EOF, wrong-response-ID deadline fallback, valid resumption, concurrent calls, and bounded cancellation. Controlled-future setup tests cover start/exit waits, redaction, error classification, and retention bypass. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: MCP tool calls fail when a response stream ends without a result and time out instead of waiting indefinitely for unresponsive servers. CHANGELOG-OZ: Cloud runs report which environment setup command timed out instead of waiting until the sandbox expires. ## Context - [Investigation](https://staging.warp.dev/conversation/51ce1eb5-53d0-48ad-ba47-011e95f3f5fc) - [Implementation plan](https://staging.warp.dev/drive/notebook/SMsGlyfJqt4xaTkvzIMVMh) - [rmcp reproduction and upgrade](https://staging.warp.dev/conversation/e8699cc5-66db-473c-a67c-ab2d7788908e) Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: seemeroland <rhuang97@gmail.com> Co-authored-by: Warp <agent@warp.dev>

…otdev#16251) ## Description Skip undo-close cleanup when the PaneGroup is absent from the window's view registry. Checking only that the window remains open allows `Circular view update` panics during closed-item discard. This follows the adjacent conversation-history guard. Live PaneGroups still receive cleanup. Unavailable PaneGroups are skipped permanently, with no deferral or retry, as requested. This is separate from the older deferral alternative in [PR 11352](warpdotdev#11352). ## Linked Issue [APP-4553](https://linear.app/warpdotdev/issue/APP-4553), specifically the production undo-close stack in Sentry [7X4K / 7564730124](https://warpdotdev.sentry.io/issues/7564730124/) and [89PS / 7703126549](https://warpdotdev.sentry.io/issues/7703126549/). - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Internal Linear issue; implementation explicitly approved in the request. - [x] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing - No automated tests added, per requester instruction. Pre-existing tests are unchanged. - `cargo clippy -p warp --all-targets --tests -j 2 -- -D warnings`: passed on the current test-free change. - `cargo build -p warp --bin warp -j 2`: passed on the current test-free change. - `./script/format` and `git diff --check`: passed. The final diff contains only the production PaneGroup presence check. - Linux baseline and same-guard UI: created/split/closed tabs, navigated through the 5-second grace period, and ran a command in the surviving terminal. Both stayed responsive. The timing-dependent unavailable-PaneGroup crash was not reproduced in the GUI. Reopen dispatch was observed, but restoration was not visually conclusive. - A verification agent ran `cargo build --bin warp` successfully on macOS 26.6 arm64 at `17c8a8a723f4a6df4f37bbb0ad9000c02ee6ba63`, which has the same production guard. Mac GUI verification was blocked by shield/AVFoundation capture failure; the timing-dependent crash was not reproduced. Windows verification remains unconfirmed. - Linux account sync returned `Expected a user account`; the rendered local terminal was usable, but full account authentication was not verified. - [ ] I have manually tested my changes locally with `./script/run`. Used the successfully built internal `target/debug/warp` binary instead. ### Screenshots / Videos The captures document ordinary Linux tab expiration, not the unavailable-view crash.  - [Finished-build tab-close/expiration recording](https://platform.staging.warp.dev/nY3TTyeghJ9csPsKTVa0bE/runs/01a0fa1b-e97a-7f17-9114-ed85619aed7b/artifacts/01a0fa3c-f140-7806-85d6-d2e954c085ae) - [Baseline tab-close/expiration recording](https://platform.staging.warp.dev/nY3TTyeghJ9csPsKTVa0bE/runs/01a0fa1b-e97a-7f17-9114-ed85619aed7b/artifacts/01a0fa2e-190c-7c04-911d-9b1b78c1ab3c) - [Finished-build undo-close settings](https://platform.staging.warp.dev/nY3TTyeghJ9csPsKTVa0bE/runs/01a0fa1b-e97a-7f17-9114-ed85619aed7b/artifacts/01a0fa3a-9261-7e7f-b267-27f046b2b49e) - [Responsive terminal after expiration](https://platform.staging.warp.dev/nY3TTyeghJ9csPsKTVa0bE/runs/01a0fa1b-e97a-7f17-9114-ed85619aed7b/artifacts/01a0fa3c-d672-72f0-b4e0-4eb7b0543db0)  ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode. Created by Warp Factory. CHANGELOG-BUG-FIX: Fixed a crash during undo-close cleanup when a tab's pane group is unavailable. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

…#16249) ## Description Skip best-effort settings-error synchronization when the Settings pane cannot be checked out, instead of panicking. The workspace still retains its current error state, and available panes receive normal error, dismissal, and clear updates. This uses `try_update` without retries, deferrals, logging changes, or framework changes. A temporarily unavailable pane can miss that update until the next synchronization. This is the requested skip behavior. `open_settings_pane` and undo-close handling are unchanged. Correlates with settings-file sync stacks in [Sentry 7ZHG](https://warpdotdev.sentry.io/issues/7581538546/) and [89HX](https://warpdotdev.sentry.io/issues/7700913091/). The separate open-Settings stacks (7Z7V/89F4) are outside this change. ## Linked Issue [APP-6223](https://linear.app/warpdotdev/issue/APP-6223) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Tracked in Linear with `factory:wilson`. - [x] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing - No new automated tests, as requested. All pre-existing tests remain unchanged, including the unrelated sync-queue cancellation test. No tests were run locally for this test-removal revision. - `cargo clippy -p warp --lib --tests -- -D warnings`: passed; compiles and lints the remaining tests. - `cargo build -p warp --bin warp`: passed. Final targeted Rust formatting used repository options; both test files match the PR base byte-for-byte. The net diff contains only the production fix in `app/src/workspace/view.rs`. - Historical [full CI, attempt 2](https://github.com/warpdotdev/warp/actions/runs/36956489570/attempts/2) passed on `a91db2522` before test removal. - Current-head CI on `0d99ac48e` remains failed after the single bounded retry. [Attempt 1](https://github.com/warpdotdev/warp/actions/runs/36962831446/attempts/1) failed Windows `test_explicit_rejection_does_not_retry` (`network_tests.rs:457`). [Attempt 2](https://github.com/warpdotdev/warp/actions/runs/36962831446/attempts/2) passed that test but failed `test_explicit_termination_does_not_retry` (`network_tests.rs:480`, `Explicit termination must be terminal`). Both attempts had 11,961 Windows unit tests pass, 1 fail, and 51 skip. These unchanged shared-session tests are outside the Settings diff. No MCP or TUI unit-test failures appeared in attempt 2. The required CI aggregate is failed; further retries are stopped. Linux/macOS tests and lint/compile checks passed in attempt 1. - Linux source-built local-channel UI: invalid TOML produced the workspace banner; after dismissal and another invalid write, the Settings footer showed its error card. Restoring the original file cleared the footer. The client stayed responsive. - The recording shows the banner, dismissal, and Settings-tab switching only. Footer error and clearing are screenshot evidence, not recorded footage. The first dismissal coincided with an automatic settings-file rewrite; another invalid write exercised the footer path. The timing-dependent unavailable-pane crash and cross-window variant were **not reproduced**. macOS/Windows UI verification remains unperformed. - [ ] I have manually tested my changes locally with `./script/run`. Used `cargo run --bin warp` with the pinned channel-config helper instead. ### Screenshots / Videos  [Video: Linux settings-file error banner and dismissal (no footer or clearing footage)](https://platform.staging.warp.dev/artifacts/01a0fa34-7d33-717d-b59b-d93c962dfa72) [Screenshot: workspace error banner](https://platform.staging.warp.dev/artifacts/01a0fa33-8a02-73b2-9461-f0881e02b712) · [Screenshot: dismissed-banner footer error](https://platform.staging.warp.dev/artifacts/01a0fa34-3a0c-7dcb-bfee-49cfc4318122) · [Screenshot: cleared footer](https://platform.staging.warp.dev/artifacts/01a0fa34-77ae-73ac-b646-3d3d418f0cc2)  ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed a crash when settings-file errors update an unavailable Settings pane. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

## Description Replace `CLIAgentType` with an exhaustive `CLIAgent::telemetry_name()` mapping so Rust variant names can change without changing analytics values. Keep `CLIAgent` and `Option<CLIAgent>` throughout all telemetry events and emitters. Convert to static strings only in outbound payloads and field serializers, including notifications and code review. Preserve all 19 values, including `Cursor`, optional/null fields, and the nested notification key `c_l_i_agent`. Leave `CLIAgent` serde and session-sharing serialization unchanged. Notification telemetry is outbound-only and implements `Serialize`, not `Deserialize`. ## Linked Issue [Approved request](https://warpdev.slack.com/archives/C0BUDAYSD36/p1790897495385679); no tracked issue or spec for this scoped refactor. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. Not applicable; implementation was approved directly. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). Not applicable; telemetry-only change. ## Testing - `cargo check -p warp --tests --locked` — passed; existing test targets compile. - `cargo clippy -p warp --all-targets --tests --locked -- -D warnings` — passed. - `./script/format` and `git diff --check` — passed. No new tests: this representation-only refactor preserves emitted behavior. No tests were executed in this validation pass. Checks ran on Linux; cross-platform/workspace CI remains unverified. - [ ] I have manually tested my changes locally with `./script/run`. Not applicable; no rendered behavior changed. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

## Description On a Windows runner, `gh` never sees the GitHub credential the client writes, because the client puts `hosts.yml` where `gh` doesn't look. The client always wrote `~/.config/gh/hosts.yml`. `gh` reads its config from `GH_CONFIG_DIR`, then `$XDG_CONFIG_HOME/gh`, then `%AppData%\GitHub CLI` on Windows, and only then `~/.config/gh`. `APPDATA` is always set on Windows, so the file was never read there. The client now resolves the directory in that same order. `GH_CONFIG_DIR` and `XDG_CONFIG_HOME` apply on every platform, as they do for `gh` itself. The `%AppData%` step applies only on Windows. `write_gh_hosts_yml` now takes the resolved directory instead of the home directory, so its tests don't depend on the host environment. On other platforms, a sandbox that sets `GH_CONFIG_DIR` or `XDG_CONFIG_HOME` now gets `hosts.yml` there, which is where `gh` was already reading. Without those variables nothing changes. Not covered here: `glab` still gets `~/.config/glab-cli`, and I haven't checked where it reads on Windows. The location of `~/.git-credentials` on Windows is a separate bug, fixed in warpdotdev#16236. ## Linked Issue No linked issue. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. There's no issue to label. - [ ] Screenshots or a video are included. This isn't a user-visible change. ## Testing I added a table-driven test for the resolution order. It covers the `GH_CONFIG_DIR` and `XDG_CONFIG_HOME` precedence, the Windows-only `APPDATA` step, empty variables, and the home-directory fallback. The three existing `hosts.yml` tests now pass the config directory directly. - `cargo nextest run -p warp --lib git_credentials`: 33 passed. - `cargo clippy -p warp --all-targets --tests -- -D warnings`: clean. - `./script/format` ran last and changed only the two files in this PR. The resolution order comes from the `gh` documentation for `GH_CONFIG_DIR`. I haven't run this branch on a Windows runner. It reaches runners after a client release and a rebuilt Windows agent image. Please check `gh auth status` on a Windows run once that ships. - [ ] I have manually tested my changes locally with `./script/run`. I didn't launch the app, because this code only runs in cloud agent sandboxes. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed the GitHub CLI not being authenticated for cloud agents on Windows runners. Co-authored-by: Warp <agent@warp.dev>

## Description Adds `FeatureFlag::WindowsVideoRecording` to `RELEASE_FLAGS`, next to `VideoRecording`. On Windows, `video_recording_enabled()` requires both `VideoRecording` and `WindowsVideoRecording`. Only `VideoRecording` is in `RELEASE_FLAGS`; `WindowsVideoRecording` is dogfood-only. So a stable client on a Windows cloud runner never advertises `StartRecording` / `StopRecording` in its supported tools, and the server leaves `start_recording` / `stop_recording` out of the computer-use agent's toolset. Screenshots don't use either flag, which is why they work while video doesn't. The Windows `gdigrab` recorder itself is already in stable (`crates/computer_use/src/windows/recording.rs`), and `ffmpeg.exe` ships in the Windows sidecar image. This change only flips the rollout gate. The flag stays in `DOGFOOD_FLAGS`, and it can still be turned back off independently of the macOS and Linux recorders by removing this line. ## Linked Issue - [ ] 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 nextest run -p warp_features`: passes. - `cargo clippy -p warp_features --all-targets --tests -- -D warnings`: clean. - I did not run the Windows recorder end to end with this flag on a stable build, and I did not run the app locally. The behavior was traced through the code: the client gate in `recording_controller.rs`, the supported-tools list in `ai/agent/api/impl.rs`, and the server's `AreToolTypesSupported` check for the computer-use agent. - Please confirm with the REMOTE-2064 owner that Windows recording is ready for stable before merging. Windows cloud runners now run the agent in the logged-in desktop session (Namespace enabled interactive applications on the prod workspace), which `gdigrab` needs. A staging run with a Dev client, where the flag is already on, is a good check. - [ ] I have manually tested my changes locally with `./script/run` ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  Co-authored-by: Warp <agent@warp.dev>

## Description Report the optional native `cache_write_input_tokens` counter from Codex rollout checkpoints in cumulative and attributed harness usage. Preserve absent fields as unknown/omitted and explicit zero as measured zero. Repeated checkpoints do not double-count, model changes receive confirmed deltas, and mismatched or missing last-usage deltas remain unattributed. This client PR only reports usage and does not change pricing or billing. The companion server PR warpdotdev/warp-server#18766 adds benchmark list-price estimates for native Codex cache writes, replacing ordinary input pricing for separately priced writes to avoid double-counting; billing remains unchanged. No Codex binary version bump is included; older Codex histories missing this field remain unknown. The existing typed publication path serializes the new optional field directly, so no adapter change is required. **Server-first rollout:** warpdotdev/warp-server#18766 must land and deploy before this client change lands or ships. ## Linked Issue No issue supplied. Coordinated server PR: warpdotdev/warp-server#18766. ## Testing - `cargo nextest run -p warp_harness_usage` — 29 passed, including five new cache-write regression tests checking both aggregate and attributed counts. - `cargo clippy -p warp_harness_usage --all-targets --tests -- -D warnings` — passed. - `RUSTC_BOOTSTRAP=1 cargo fmt -p warp_harness_usage -- --config imports_granularity=Module --config group_imports=StdExternalCrate` — passed once after tests and lint. - `git diff --check` — passed. - No full presubmit run; no tests or lint rerun after formatting, per AGENTS.md. - [ ] I have manually tested my changes locally with `./script/run` Manual end-to-end publication was not run; coordinated server deployment is required. No GUI changes. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode [Conversation](https://staging.warp.dev/conversation/6f75a244-7b6a-4c6f-84d9-4efeebba17c2) · [Agent run](https://platform.staging.warp.dev/runs/01a0f7f9-cc6f-7a78-b253-78b7dd817041) CHANGELOG-IMPROVEMENT: Codex run usage now reports cache-write token counts when available. Co-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev>

## Description Align fish and PowerShell right prompts with the terminal edge instead of applying zsh's one-cell inset. Rust selects margins from the existing shell identity: fish/PowerShell 0, zsh/Bash/unknown 1. Input placement uses the existing displayed-prompt block while the new active block awaits shell metadata. No bootstrap, marker protocol, cache schema, or persistence changes are needed. ANSI behavior is unchanged. Custom `ZLE_RPROMPT_INDENT` values are not supported; a short TODO records that follow-up. ## Linked Issue Related to warpdotdev#3358; this fixes right-prompt placement, not every theme issue in that report. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. It is an existing triaged support issue. - [x] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing - No new tests, as requested. `cargo check -p warp --lib --tests` passed; Rust formatting and `git diff --check` completed. - The unchanged production code passed `cargo clippy -p warp --all-targets --tests -- -D warnings` and `cargo build --bin warp-oss --features gui`. - Source-built Linux GUI: real Tide 6.2.0 on fish 4.9.3, typing/execution and fresh active/completed frames at 124 and 60 columns; minimal fish frame control; default zsh 5.9 one-cell inset. Captures below show this production behavior. - Existing fixed-width frame strings remain stale when historical blocks resize; this fix does not redraw them. No live PowerShell/Oh My Posh verification. - [ ] I have manually tested my changes locally with `./script/run`. Used the successful Cargo-built source binary directly instead. ### Screenshots / Videos  [Final source-build Linux verification video](https://platform.staging.warp.dev/artifacts/01a0fe60-732a-7d5b-a708-eb30904d3f44) Screenshots: - [Real Tide: active and completed prompt, 124 columns](https://platform.staging.warp.dev/artifacts/01a0fe5d-912b-797a-be23-38cffbb21b86) - [Real Tide: narrow 60-column pane](https://platform.staging.warp.dev/artifacts/01a0fe5d-e894-742f-a1c7-b3465f37423c) - [Minimal fish frame: 124 columns](https://platform.staging.warp.dev/artifacts/01a0fe5e-7d2b-7859-9c82-f47f91ac0e63) - [Minimal fish frame: 60 columns](https://platform.staging.warp.dev/artifacts/01a0fe5f-03cd-79f5-954b-2b68d4626f70) - [Default zsh: one-cell inset](https://platform.staging.warp.dev/artifacts/01a0fe60-213d-792e-b6a6-42f84456c9b9)  ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Align fish and PowerShell right prompts with the terminal edge while preserving zsh's default spacing. --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

…otdev#14396) ## Description Defers inline history menu selection until the current view update completes. Both Up and Down could otherwise update `InlineHistoryMenuView` while it was already removed for an in-progress update, causing a `Circular view update` panic. Deferring the menu update itself covers navigation from the macOS History action (`InputAction::Up`) and editor Down. Closes warpdotdev#8917. Related: APP-5729. ## Linked Issue - [x] 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). Not applicable; no visual change. ## Testing - [x] Seeded two history commands; nested History/Up and Down move the selected item and editor preview (`ls` → `cd ~` → `ls`) - [x] Empty Down still closes the menu after the nested checkout ends - [x] Focused `cargo nextest run -p warp --lib` for the re-entrancy tests and nearby history tests — 4 passed - [x] `cargo clippy -p warp --all-targets --tests -- -D warnings` - [x] `./script/format` - [ ] I have manually tested my changes locally with `./script/run` — computer-use launch is blocked without `warp-channel-config` The production crash depends on re-entrant event timing. The tests force that view-update ordering. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  CHANGELOG-BUG-FIX: Fixed a crash when navigating terminal history with the Up or Down Arrow. ---------

warpdotdev#16268) ## Description Return a completed empty native response when zsh's completion system is uninitialized, so Warp can use its existing filepath fallback. Completion errors must also end the response instead of leaving the client waiting. The armed ZLE widget owns the response frame rather than relying on `_main_complete` pre/post hooks. Captured candidates and replacement spans survive nonzero completion status, with exactly one begin/end pair. This does not run `compinit`, change native-completion defaults, or change the wire format. ## Linked Issue Refs warpdotdev#16223. This addresses the proved native-ON missing-response path; the reporter's persistent native-OFF symptom remains unconfirmed. - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. The requester approved this change; the issue currently has `needs-info`. - [ ] Where appropriate, screenshots or a short video of the implementation are included below. Post-fix macOS verification is pending. ## Testing - Added one zsh-only regression to the existing integration framework. With Warp/native completions both ON and no `compinit`, Tab for an unknown command shows both matching filepath fixtures. The same test fails at the filepath assertion with the base bootstrap. - `WARP_SHELL_PATH=/usr/bin/zsh cargo run -p integration --bin integration -- test_zsh_native_completions_without_compinit_use_filepaths`: focused app build and test pass on Linux/zsh 5.9. - `WARP_SHELL_PATH=/usr/bin/zsh cargo nextest run -p integration -E 'test(test_zsh_native_completions_without_compinit_use_filepaths) or test(test_native_shell_completions_menu)'`: 2 passed, including the existing initialized-native control. - `cargo clippy -p integration --all-targets --tests -- -D warnings`, `zsh -n app/assets/bundled/bootstrap/zsh_body.sh`, and whitespace checks pass. Applied the repository-configured Rust formatter afterward. - Real PTY/ZLE diagnostics also confirmed complete framing on return errors and runtime errors after capture, preserving candidates and spans. No new harness or CI wiring is included. - [ ] I have manually tested my changes locally with `./script/run`. macOS app verification is coordinated separately; no packaged macOS rebuild has been performed. ### Screenshots / Videos Post-fix visual proof is pending; reproduction recordings are not verification of this branch. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-BUG-FIX: Fixed native zsh completion requests not returning when shell completions are uninitialized or fail.   --------- Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Andy <andy@warp.dev>

…pdotdev#16271) ## Description Wait for the notebook editor's `layout_complete()` future before looking up the runnable command in `test_command_block_dispatches_event`. Windows CI intermittently fails at `Command should exist` before dispatch because notebook loading only awaits edit-access work. Layout events create command child models. The foreground task drains those event subscriptions before the awaiting test resumes. Keep the wait local to this test; preserve the shared loading helper and exact workflow/event assertions. No production changes, sleeps, retries, or skipped assertions. ## Linked Issue [APP-6241](https://linear.app/warpdotdev/issue/APP-6241/notebook-command-dispatch-test-intermittently-reads-command-before) - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. — Implementation authorized; the Linear issue is In Progress without these labels. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). — Not applicable: test-only synchronization. ## Testing The existing dispatch test remains the regression check; no duplicate test was added. - Passed locally: `./script/format` and `git diff --check`. - [Windows verification logs](https://platform.staging.warp.dev/nY3TTyeghJ9csPsKTVa0bE/runs/01a0ffe9-6371-7960-a734-4caf6615ba18): native baseline and fixed test compilation passed (x86_64 MSVC, Rust 1.92.0). - Fixed `feb5f9e9500469b40555edcb2a956e9f31b72131`: 200/200 isolated target runs and 125 notebook tests × 20 eight-way concurrent runs passed (2,500/2,500). All used `--retries 0` and exited 0. - Windows command prefix: `cargo nextest run --locked -p warp --lib --features integration_tests,tui,nld_classifier_v3,nld_heuristic_v2,test-util`. Isolated filter: `-E 'test(=notebooks::notebook::tests::test_command_block_dispatches_event)' --stress-count 200 --test-threads 1 --fail-fast`; suite: `-E 'test(notebooks::)' --stress-count 20 --test-threads 8 --fail-fast`. - Baseline `1645db65cce391d4c4992b50f2672db53b01d9e7` passed 100/100 isolated runs. The flake was not reproduced; baseline concurrency was not run. This is not a failing-baseline/passing-fix comparison. - First fixed isolated run reported `LEAK` at 0.380s (`1 passed (1 leaky)`), without a panic or further details. The remaining 199 isolated runs and 2,500 suite tests had no leak warning. - Linux focused nextest/Clippy were blocked before compilation by uncached `servo/core-foundation-rs` dependencies and permission denied under `/usr/local/cargo/git/db`. Optional Windows Clippy was blocked by disk exhaustion (OS error 112); CI lint remains outstanding. - [ ] I have manually tested my changes locally with `./script/run` — Not applicable: no production UI change. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode CHANGELOG-NONE   Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com> Co-authored-by: Warp Agent <agent@warp.dev>

Joining one matched blank line is an empty string, so a deletion whose replacement is empty was counted as a no-op and never applied. Compare the line sequences instead.

warp-agent-staging · 2026-10-03T23:31:20Z

Closing: this was opened against master and includes unrelated history. Reopening against the pinned checkout commit.

seemeroland and others added 30 commits September 9, 2026 14:40

warp-agent-staging Bot and others added 28 commits September 29, 2026 20:40

Bump minimum codex plugin version (warpdotdev#16214)

c0b7cf9

Apply V4A edits that only delete a blank line

4131f55

Joining one matched blank line is an empty string, so a deletion whose replacement is empty was counted as a no-op and never applied. Compare the line sequences instead.

warp-agent-staging Bot closed this Oct 3, 2026

Navigation Menu

Repository navigation

Apply V4A edits that only delete a blank line - #110

Apply V4A edits that only delete a blank line#110
warp-agent-staging[bot] wants to merge 134 commits into
masterfrom
benchmark-run-151-trial-9360-attempt-1/01a10401-94ba-7227-b8b3-1228047c2d83/keep-blank-line-apply-patch

warp-agent-staging Bot commented Oct 3, 2026

Uh oh!

warp-agent-staging Bot commented Oct 3, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

19 participants