[FEATURE] Esc-to-rewind should rewind the focused teammate, not the team lead (or docs should clarify)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

In agent teams (in-process mode), when I'm focused on a teammate and want to rewind the teammate's conversation, pressing Esc to rewind ends up rewinding the team lead's conversation instead of the focused teammate's. I'd expect the rewind to act on whichever session currently has focus.

The docs (Orchestrate teams of Claude Code sessions) describe teammates as "full, independent Claude Code sessions" that you can interact with directly by pressing Enter and typing. That framing sets the expectation that all session-level controls — including rewind — should work per-teammate. But in practice, rewind only targets the lead, and the docs don't address this explicitly. The only rewind-related note in the docs is about resumption ("/rewind does not restore in-process teammates"), which is a different concern.

Proposed Solution

Either:

1. Make Esc-to-rewind respect the currently focused session. If I'm viewing teammate companion-v2 (entered via Shift+Down + Enter), pressing Esc-to-rewind should rewind companion-v2's conversation, not the lead's. The same should apply to /rewind when invoked from inside a teammate's view.

1. Or, explicitly document that per-teammate rewind is unsupported and that rewind always targets the lead — so users don't expect it to work per-teammate and aren't surprised when it doesn't.

Option 1 is the better UX; option 2 is the minimum to close the ambiguity.

Alternative Solutions

• Manually spawn a replacement teammate when I want to effectively "undo" a teammate's work. This is a heavy workaround — I lose all of that teammate's in-context state.
• Use the lead to instruct the teammate to revert, which is also lossy and doesn't actually rewind the context.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. I spawn an agent team weave with teammate @companion-v2.
2. I give @companion-v2 some direction, it does a few turns of work, and I realize two turns ago I pointed it in the wrong direction.
3. I press Enter on the lead's list to focus @companion-v2, then press Esc to rewind its conversation back two turns.
4. Expected: @companion-v2's conversation rewinds by two turns; the lead's conversation is untouched.
5. Actual: the lead's conversation rewinds instead; @companion-v2's state is unchanged.

Possibly a Regression

I'm not 100% sure, but I could have sworn that Esc-to-rewind used to act on the focused teammate's session in an earlier version of Claude Code. I don't have a specific version to point to, but worth flagging in case this is a regression rather than a never-implemented feature — if it's a regression, reframing this issue as a bug report would be more accurate.

Additional Context

Related docs excerpts:

• "Each teammate is a full, independent Claude Code session." — Talk to teammates directly
• "/resume and /rewind do not restore in-process teammates." — Limitations (scope is resumption, not per-teammate rewind)
• "Press Enter to view a teammate's session, then Escape to interrupt their current turn." — this describes Esc as an interrupt in teammate view, which is consistent with what I see for an in-flight turn, but leaves open what Esc should do when no turn is running (currently: rewinds the lead).

My environment (same as the other team-related bugs I've filed recently):

• Claude Code 2.1.112
• macOS
• iTerm2 inside tmux (note: my teams are running in in-process mode, but I am also inside tmux at the shell level)
• Opus 4.7

Cross-reference: I have two separate team-related bug reports open that may share root causes around session-boundary state handling — #49865 (getAppState crash on teammate permission request) and #49944 (pasted text not reaching teammate). This request may share plumbing with those issues.