You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Mobile: tapping a question option permanently deletes the typed custom answer #34980
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
Mobile app (iOS/Android): pending question card
Steps to reproduce
In the mobile app, open a thread where the agent asks a question that has options and allows a custom answer.
Type a few sentences into the custom-answer field.
Tap one of the options.
Expected behavior
The typed text is not destroyed. On web this was fixed for #12569 by #12577: onSelectActivePendingUserInputOption (apps/web/src/components/chat/usePendingThreadRequests.ts) carries the displaced text into the composer draft with carryDisplacedCustomAnswerIntoPrompt and shows "Your typed text was set aside".
Actual behavior
The text is gone, and nothing brings it back. On mobile, setUserInputDraftOption (apps/mobile/src/state/use-selected-thread-requests.ts) calls togglePendingUserInputOptionSelection, which returns customAnswer: "" (packages/client-runtime/src/state/pendingUserInput.ts). Unlike web, nothing saves the old value first: no set-aside, no toast, no undo.
Impact
Data loss of user-written text. One mis-tap on an option while writing a longer answer on a phone erases it.
I tried to reproduce this on the current build and could not.
Commit dc032d7 (origin/main). I ran a fresh dev server (T3CODE_DEV_SEED=0, --host 0.0.0.0) and Metro, then installed the cached Android dev client on a pooled Pixel 9 (API 36) and paired it over the tailnet. The free Replay (dev) 'question' scenario rendered a pending question card on the device, but it had no custom-answer field. ACP enum elicitations are mapped to allowCustomAnswer: false, so no replay scenario can show options together with a custom answer. I then started an OpenCode thread (model opencode/deepseek-v4.1-flash-free) whose question was pending ('Waiting for 1 answer(s)'). The device pool failed before I could type into its custom-answer field and tap an option on the device. Two leases expired while I waited on installs, and the third install failed with 'the worker holding this device is not connected to the gateway', so I did not see the text disappear on a device myself. The code path the reporter cites does match main: setUserInputDraftOption (apps/mobile/src/state/use-selected-thread-requests.ts:66-83) writes the result of togglePendingUserInputOptionSelection, which always returns customAnswer: "" (packages/client-runtime/src/state/pendingUserInput.ts:146-157), and nothing saves the old value first. Cleanup is done: servers stopped, sessions closed, worktree and scratch directory removed.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.
Activity
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Commit dc032d7 (origin/main). I ran a fresh dev server (T3CODE_DEV_SEED=0, --host 0.0.0.0) and Metro, then installed the cached Android dev client on a pooled Pixel 9 (API 36) and paired it over the tailnet. The free Replay (dev) 'question' scenario rendered a pending question card on the device, but it had no custom-answer field. ACP enum elicitations are mapped to allowCustomAnswer: false, so no replay scenario can show options together with a custom answer. I then started an OpenCode thread (model opencode/deepseek-v4.1-flash-free) whose question was pending ('Waiting for 1 answer(s)'). The device pool failed before I could type into its custom-answer field and tap an option on the device. Two leases expired while I waited on installs, and the third install failed with 'the worker holding this device is not connected to the gateway', so I did not see the text disappear on a device myself. The code path the reporter cites does match main: setUserInputDraftOption (apps/mobile/src/state/use-selected-thread-requests.ts:66-83) writes the result of togglePendingUserInputOptionSelection, which always returns customAnswer: "" (packages/client-runtime/src/state/pendingUserInput.ts:146-157), and nothing saves the old value first. Cleanup is done: servers stopped, sessions closed, worktree and scratch directory removed.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.