IME cannot be activated in the composer textarea (Chinese input) until the window is reopened

[e29denghy]

Describe the bug
In the chat composer (input box), I often cannot switch to / activate the
Chinese input method (IME). Typing stays in English mode no matter what.
Page reload (Cmd+R) does NOT fix it — the only recovery is fully closing
the window and reopening it.

Environment

• DSH: dev build from the local repo, boot rev b7ed136eb504,
  git HEAD 47f943859b (master), package version 0.1.0-rc.5,
  served on http://127.0.0.1:3080 (HMR enabled)
• OS: macOS 26.5 (Build 25F71), Apple Silicon (arm64)
• Browser: Chrome
• IME: macOS built-in 简体拼音 (Simplified Pinyin)
• How it's launched: dsh web dev server from the source checkout

Steps to reproduce

1. Open the DeepSeek Harness web UI and start a session.
2. Click into the input box and use the system shortcut to switch to
   Chinese input.
3. Type — no Chinese candidates appear; only English characters are inserted.
4. Sometimes it works at first but breaks again after some interaction
   (e.g. after sending a message / switching sessions).

Expected behavior
The system IME should activate normally in the composer, as it does in
any other text field.

Actual behavior
Chinese input cannot be engaged. Cmd+R (page reload) does NOT recover it —
the IME stays dead. Only closing the window/tab and opening a new one
(which creates a fresh renderer process) restores Chinese input.

Workaround
Close the tab and open a new tab to the same URL (faster than closing the
whole window, same effect: new renderer process). Full window close/reopen
also works.

Additional context

• Since reload reuses the renderer process and does not fix it while a new
  renderer does, the stuck state looks like a browser-level IME session
  that got wedged in the renderer process, not page DOM state.
• Possible trigger: programmatic el.focus() during IME composition, or
  preventDefault() on keys while composing — see
  packages/client/ui-conversation/src/client/skeleton/InputBar.tsx
  (composition guard + onChange → keyboard.setDraft + the unlock
  effect that calls focus() on mount / session switch).
• Screenshot / screen recording: (optional)
• Console errors: (optional)

[moonquake2004]

Same bug here — reproduced on 0.1.0-rc.6 (web profile) with the 豆包 (Doubao) IME: after a while the composer stops accepting Chinese entirely (English only), and only a fresh window/process recovers it. Your renderer-process observation matches — it's the browser-level IME session that wedges, not page DOM.

Your hypothesis points in the right direction. I went through the same code (dsh-client-ui-conversation/lib/client.js) and found the concrete triggers, ranked:

1. Programmatic el.focus() on locked/sessionId change (~L3423-3428): a useEffect calls inputRef.current.focus() whenever locked flips (a round starts/ends) or the session changes. If that lands while the user is mid-composition, it terminates the composition and — on macOS third-party IMEs — can wedge the IME's text-service connection until the renderer is recreated. "Breaks after sending a message / switching sessions" fits exactly.
2. Controlled-value writes during composition: the textarea is controlled (value: draft) and draft is rewritten programmatically — failed-send restore (setDraft(text) on prompt error, ~L1445) and input-trigger splices (consumeToken/insertText, ~L1136/L1158). A value write mid-composition has the same wedge effect.
3. composingRef reset via setTimeout(…, 10) after compositionend (~L3376-3380): races with rapid successive compositions — the guard can clear during the next composition, so Arrow/Space/Enter handlers preventDefault() IME keys; if the component unmounts mid-composition it stays true forever (Enter stops sending).
4. readOnly toggles with machineBusy (~L3796) — same family, lower likelihood.

Also worth linking the sibling reports about the transparent textarea: #629, #1417, #1281 — the composer draws text via a backdrop mirror (color: transparent on the real textarea), so the browser-painted IME preedit underline/candidates are invisible. Different manifestation (you can type but can't see candidates), same InputBar composition-handling area.

Fix direction (any one materially helps): never call focus()/write the controlled value while composing (guard with composingRef || e.nativeEvent.isComposing), reset composingRef synchronously on compositionend + blur (drop the setTimeout), and defer draft restore while composing.