Agent Host chat input reverts while typing after draft sync rejection

[roblourens]

Problem

Text typed into the chat input for an Agent Host session can repeatedly disappear, leaving the input reverted to an earlier prefix. In the reported case, the input kept returning to I want to as additional words were typed.

The Agent Host protocol logs show this sequence:

1. I want to was the last server-confirmed chat/draftChanged value.
2. The UI remained open and editable after the host considered the backing session explicitly deleted.
3. Each longer draft was sent optimistically through chat/draftChanged.
4. The host rejected each action with Session was explicitly deleted.
5. Subscription state returned to the last confirmed draft, and that state was reflected back into the live chat input.

As a result, every newly typed suffix disappeared shortly after draft synchronization ran. The same state transition can also occur when reconnect processing replaces optimistic state with a fresh server snapshot.

Expected

Failure to synchronize a draft should not destroy text currently being edited locally.

Actual

A protocol rollback or snapshot can be interpreted as an incoming draft update and overwrite the live editor contents. This can make the input appear impossible to type into while the underlying session remains stale or unavailable.

(Written by Copilot)

[roblourens]

Additional investigation suggests that the deleted session is the underlying lifecycle problem, while the draft rollback explains the repeated input loss.

The affected session was an eagerly created, unpublished draft owned by a different VS Code client/window. The observed sequence was:

1. Client A created the eager draft session.
2. The draft URI was opened in a new editor window, Client B. Client B subscribed successfully and began editing it.
3. Client A was later removed from the session. Immediately afterward, the session began rejecting Client B's actions with Session was explicitly deleted.
4. The ordering closely matches the normal NewSession.dispose() path: release the creating client's subscription/active-client contribution, then call disposeSession() for the eager backend session.

This indicates that opening an eager draft in another window shares its URI without transferring or sharing ownership. The original NewSession still considers itself the sole owner and may delete the backend when its draft is discarded, even though another client is actively subscribed and editing it.

Because the draft was unpublished, its deletion did not produce a normal root/sessionRemoved notification. Client B therefore remained attached to stale session state and continued presenting an editable input. Subsequent draft updates and the eventual chat/turnStarted were all rejected.

The bundle does not include Client A's AHP connection log, so the exact UI gesture that discarded the original draft is unknown. It could have been closing the draft, creating another new session, closing all sessions, or another normal draft-replacement path. However, the following conclusions have high confidence:

• The affected editor window did not issue the deletion.
• Empty-session GC is unlikely because Client B remained continuously subscribed.
• The host session was explicitly tombstoned through disposeSession().
• The likely architectural issue is cross-window ownership of eagerly created draft sessions.

(Written by Copilot)