Fix CLI subagent interactions for oz agents

[seemeroland]

Description

Was investigating sources of ambient agent tasks becoming canceled by user automatically: https://linear.app/warpdotdev/issue/REMOTE-1887/maa-requests-getting-canceled#comment-75459dec

It can happen when we receive a NotInteracting LRC state, which is interpreted as user takeover of a CLI subagent monitored requested command. This is meant to cancel the conversation stream because the agent is no longer monitoring, but it also set the conversation status to canceled, which updates the ambient agent state to canceled by user.

But I also see the sharer receiving NotInteracting from the viewer when not expected. I believe there may be stale updates from the viewer causing this. We definitely should have LRC state updates apply to a specific block so we can discard stale updates.

And finally, some bugs with cloud mode were causing echoes of LRC state updates. The problematic flow was:

• Sharer updates LRC state, fans out result
• Cloud mode viewer applies LRC update from sharer locally
• But cloud mode viewer mutation locally would result in LRC update, which gets fanned out to sharer because cloud mode viewer has write permission
• Sharer receives echo of its LRC update, as if viewer wrote it

So this is a combination of 3 fixes:

• User takeover of a LRC should keep the conversation and task status in progress
• In shared sessions, LRC state updates should apply to specific blocks so stale updates can't apply
• Prevent viewer replaying sharer LRC updates from writing again to shared session

Requires protocol change to be merged first, before updating cargo.toml: warpdotdev/session-sharing-protocol#27

Testing

• I have manually tested my changes locally with ./script/run

Screenshots / Videos

Tested with warpdotdev/session-sharing-protocol#27

https://www.loom.com/share/f09e7b1d7e35412a99a7c2947104a460

[oz-for-oss]

@seemeroland

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR keeps LRC user takeover from marking the conversation/task as cancelled and adds block-scoped LRC interaction updates for shared sessions. I did not find approved spec context for this PR; the security pass did not identify separate security issues.

Concerns

• The code now imports and populates LongRunningCommandAgentInteraction, but the PR diff does not update the session-sharing-protocol dependency/Cargo lockfile to a revision that provides that type and the new universal context fields. Unless master has already been updated separately, this will fail to compile.

Verdict

Found: 0 critical, 1 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[seemeroland]

/oz-review

[oz-for-oss]

@seemeroland

I'm re-reviewing this pull request in response to a review request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR updates CLI subagent cancellation semantics, adds block-scoped long-running-command interaction state to shared-session context updates, and suppresses remote update echoes for viewer event replay. The protocol update and visual evidence are present, and I did not find security-specific issues in the changed lines.

Concerns

• CLISubagentUserTakeover can still fall through to send_follow_up_for_conversation when the drained action phase contains any other completed result that triggers a follow-up, which contradicts the intended wait-until-command-finish/control-hand-back behavior.
• The new block-scoped LRC interaction is added to sharer initial context, but viewer join handling does not apply that field from universal_developer_input_context, so late-joining viewers can still initialize with stale interaction state until another update occurs.

Verdict

Found: 0 critical, 2 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] This guard only runs when no follow-up would be sent; if the same drained action phase has another successful result, CLISubagentUserTakeover still falls through to send_follow_up_for_conversation, so the agent resumes immediately instead of waiting for the command to finish or control to be handed back. Skip auto-follow-up for is_cli_subagent_user_takeover() before this trigger path.

[oz-for-oss]

⚠️ [IMPORTANT] This initial block-scoped LRC state is never applied by viewer NetworkEvent::JoinedSuccessfully; only later UniversalDeveloperInputContextUpdated events read long_running_command_agent_interaction. Late-joining viewers can still start with stale control/tagged-in state until another state change is broadcast, so apply this initial field during join under the remote update guard too.