Update block working directory from CLI agent cwd reports

[benjschiller]

Description

CLI agents (e.g. Claude Code via the claude-code-warp plugin) report their
working directory in the OSC 777 payload, which lands in
CLIAgentSession::session_context.cwd but never reached the block that owns the
displayed directory. As a result, an agent that changed directory mid-session —
most commonly claude --worktree, which relocates into
<project>/.claude/worktrees/<name> — left the block pinned to its launch
directory, so the WorkingDirectory chip, tab subtitle, git branch, and diff/PR
chips all stayed stale.

This bridges the agent-reported cwd into the existing OSC 7 path. When a
CLI-agent session reports a directory that differs from the block's current pwd,
it is routed through TerminalModel::set_active_block_working_directory
(extracted from the OSC 7 handler so the SSH-block guard and block-list routing
live in one place). That emits BlockWorkingDirectoryUpdated and refreshes the
downstream chips, so branch / PR / diff / tab-subtitle all update — no new event
types or UI. The OSC 7 hostname gate is intentionally not applied: the agent
cwd is already a parsed local path with no file://host component to validate,
while the is_ssh_block() guard is inherited so an agent inside an SSH-wrapped
block cannot clobber the remote block's pwd.

A spec (product + tech) is included under specs/GH10031/, matching the
ready-to-spec label on the issue. The root-cause analysis was also posted as a
comment on the issue.

Linked Issue

Fixes #10031

• 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

Unit tests added in app/src/terminal/cli_agent_sessions/mod_tests.rs cover the
session_context.cwd behavior the bridge relies on (update from event, preserve
when an event carries no cwd, record when starting empty):

cargo test -p warp --lib apply_event_
# test result: ok. 4 passed; 0 failed

cargo check -p warp passes and rustfmt --check is clean on the changed files.

The end-to-end view→block→chip path is exercised by the real-display GUI
integration harness rather than a unit test (cf.
test_osc7_updates_current_working_directory); manual verification below covers
it end to end.

• 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

CHANGELOG-BUG-FIX: CLI agent working-directory changes (e.g. claude --worktree) now update the block's directory, git branch, and diff/PR metadata instead of staying pinned to the launch directory.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Ben Schiller.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @benjschiller on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[benjschiller]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[oz-for-oss]

@benjschiller

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #10031, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz

[oz-for-oss]

@benjschiller

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #10031, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz