Type a message, move the session to a worktree before sending, and the input field is empty. Nothing was sent and nothing errored - the draft is simply gone from view. This is openchamber/openchamber#4833, fixed in PR #4974.
Why it happens
The composer persists drafts under a key built from the full identity of the conversation:
const key = JSON.stringify([runtimeKey, directory, sessionId])
Move the session to a worktree and its directory changes, so the identity changes with it. On that change the composer saves the outgoing draft under the old directory key and loads the incoming one - which is empty for the new worktree. The typed text is not lost, it is filed under the previous identity where nothing looks for it. Every move path behaves this way.
It is a small cousin of the classic stale-key bug. Any piece of state keyed on a tuple is only findable while every member of the tuple holds still, and a change to any member silently orphans it. The text is never actually lost - it sits in the draft store under the previous identity, which is how the report was traced.
The fix
Migrate the draft when the identity changes. The move now carries the typed text across with the session rather than leaving it under the old key.
If you key client-side state on an identity that can change mid-session, give the change handler one job - move the state to its new key before anything reads the new one. Renaming the key without moving the value reads exactly like data loss.