No support for `claude --worktree`

[MichalPodeszwa]

Currently when running claude --worktree from within warp - it creates a workspace in <project>/.claude/worktrees/XXX - however, Warp still sees <project> resulting in not seeing all the changes and "file explorer" showing the instead of the worktree as well.

Is there any plans to resolve this, or something I might've done wrong?

[benjschiller]

I looked into this and this looks client-side, not plugin-fixable.** Warp appears to latch a session block's working directory at terminal-launch time and never re-reads it from any agent-side event or escape sequence. The plugin already sends the correct worktree cwd on every event; Warp just doesn't use it to relabel the block. Fixing this needs a Warp-client change, so there's no plugin PR that would resolve it.

The investigation below was done with Claude Code, which ran the tests against a live worktree and reported back.

Setup: Warp v0.2026.07.08, plugin 2.1.0, Claude Code with the terminalSequence hook output field supported. Reproduced by starting Claude in a repo, then switching it into a git worktree at <repo>/.worktrees/<name> mid-session (equivalent to claude --worktree).

The plugin already sends the correct directory. Capturing the raw hook payloads confirmed build-payload.sh reads .cwd from each hook's stdin, and that field tracks the worktree correctly after the switch (cwd and the hook process's own pwd both showed the worktree path). So the plugin's data is right; Warp isn't using it to relabel the block.

Every channel a hook can use to report the new directory was tried, all delivered through the plugin's normal terminalSequence output path, all from a genuine mid-session worktree:

What was sent	Result
OSC 777 warp://cli-agent payload with correct cwd (normal plugin behavior)	block dir unchanged
OSC 7 file://<host><path>	unchanged
OSC 7 variants: empty-host, localhost, hostname; BEL + ST terminators	unchanged
Re-emitted a full session_start event carrying the new cwd	unchanged

None moved the block's working directory or file explorer.

Suggested fix (Warp client side): either (a) honor an OSC 7 sequence emitted mid-session on an agent block, or (b) update the block's cwd from the cwd field the plugin already sends on every event.

[benjschiller]

For anyone landing here: this is a Warp-client behavior, not a plugin bug — the plugin already reports the correct worktree cwd on every event; Warp just wasn't propagating it to the block's displayed directory. Tracked and being fixed upstream in the client repo:

• Issue: When I create a worktree with claude --worktree, it doesn’t update the metadata in Warp, such as the branch, PR, and changes warp#10031
• Fix (PR): Update block working directory from CLI agent cwd reports warp#13849