Description
When continuing an existing local session from a different current working directory, the Question tool UI can hang after selecting an option.
The selected option gets a green checkmark, but the prompt does not dismiss and Esc/Ctrl-C do not recover the TUI. The pending question still exists on the session directory instance. Manually replying to the same request with the correct directory query succeeds and the TUI resumes.
This appears related to #23843, but this is the local-directory variant rather than a remote workspace. It is also different from #29772: in this case the pending question is present in the correct directory instance, while the TUI reply appears to be routed to the cwd/default directory instance.
Plugins
None
OpenCode version
1.15.13
The affected session was created on 1.15.12, then continued on 1.15.13.
Steps to reproduce
-
Create a session in a project directory, for example /home/user/projects/opencode-fix.
-
From another directory, for example /home/user, continue that session with a fixed port:
cd /home/user
opencode --port 41003 -s <session-id>
-
In the TUI prompt, ask the assistant to use the Question tool, for example:
Use the question tool exactly once. Ask one single-choice question only. Set multiple false. Header: SingleFixTest. Question: Pick one option. Options labels exactly: A, B, C. Then wait for my answer.
-
When the question selector appears, press Enter on the highlighted option.
The same flow can be used for a multiple-choice question by asking for multiple: true, selecting one or more options, moving to Confirm, and pressing Enter. In the broken version, that submit path can also remain stuck because the reply is still routed without the session/question directory context.
Pressing Esc on the question prompt exercises the reject path; it can also fail to dismiss for the same routing reason.
Actual
- The selected option gets a green checkmark.
- The question UI does not dismiss.
- The pending request remains under the session/project directory instance.
- Esc/Ctrl-C do not recover the TUI; the user has to close the terminal.
Expected
The QuestionPrompt reply/reject should route to the session/question directory instance, remove the pending question, and dismiss the prompt.
Additional diagnostic evidence
After the prompt is stuck, the pending question is not visible from the default/current directory instance:
curl http://127.0.0.1:41003/question
# []
It is still visible from the original project directory instance:
curl "http://127.0.0.1:41003/question?directory=%2Fhome%2Fuser%2Fprojects%2Fopencode-fix"
# contains the pending question request
Manually replying to the pending request with the correct directory works:
curl -X POST "http://127.0.0.1:41003/question/<request-id>/reply?directory=%2Fhome%2Fuser%2Fprojects%2Fopencode-fix" \
-H "Content-Type: application/json" \
--data "{\"answers\":[[\"A\"]]}"
# trueAfter that manual reply, /question?directory=... returns [] and the TUI resumes. This suggests the Question service is healthy and the failure is in the TUI/SDK routing for question.reply / question.reject.
Likely relevant code path: packages/opencode/src/cli/cmd/tui/routes/session/question.tsx calls sdk.client.question.reply({ requestID, answers }) without passing a directory/workspace override.
API-level repro evidence
I also reproduced the underlying routing failure at the HTTP API level on v1.15.13 / 385cb694419f98103af0e8fc6187ddcbcbb6eecb, without relying on manual TUI timing. I used a container only to isolate the test environment; Docker is not required for the repro. The paths below are example directories.
Trigger a question through the session message endpoint while explicitly routing the prompt to the project directory:
POST /session/<session-id>/message?directory=%2Fworkspace%2Fopencode
Before replying, the pending question exists only in the project directory instance:
GET /question
# []
GET /question?directory=%2Fworkspace
# []
GET /question?directory=%2Fworkspace%2Fopencode
# contains the pending question request
Then reply without directory, matching what QuestionPrompt currently does:
POST /question/<request-id>/reply
# 200 true
However, the real pending request is still present in the project directory instance:
GET /question?directory=%2Fworkspace%2Fopencode
# still contains the same pending question request
Replying with the correct directory clears it:
POST /question/<request-id>/reply?directory=%2Fworkspace%2Fopencode
# 200 true
GET /question?directory=%2Fworkspace%2Fopencode
# []
So the failure can be hidden by a successful HTTP response from the wrong route/instance: the directory-less reply returns 200 true, but it does not clear the pending question in the instance that owns the request. This matches the TUI symptom where the selected option gets a green checkmark but the question prompt remains stuck.
Screenshot and/or share link
N/A
Operating System
Debian GNU/Linux 13 (trixie), Linux x86_64
Terminal
TUI/PTY; also observed in a normal terminal.
Description
When continuing an existing local session from a different current working directory, the Question tool UI can hang after selecting an option.
The selected option gets a green checkmark, but the prompt does not dismiss and Esc/Ctrl-C do not recover the TUI. The pending question still exists on the session directory instance. Manually replying to the same request with the correct
directoryquery succeeds and the TUI resumes.This appears related to #23843, but this is the local-directory variant rather than a remote workspace. It is also different from #29772: in this case the pending question is present in the correct directory instance, while the TUI reply appears to be routed to the cwd/default directory instance.
Plugins
None
OpenCode version
1.15.13
The affected session was created on 1.15.12, then continued on 1.15.13.
Steps to reproduce
Create a session in a project directory, for example
/home/user/projects/opencode-fix.From another directory, for example
/home/user, continue that session with a fixed port:In the TUI prompt, ask the assistant to use the Question tool, for example:
When the question selector appears, press Enter on the highlighted option.
The same flow can be used for a multiple-choice question by asking for
multiple: true, selecting one or more options, moving toConfirm, and pressing Enter. In the broken version, that submit path can also remain stuck because the reply is still routed without the session/question directory context.Pressing Esc on the question prompt exercises the reject path; it can also fail to dismiss for the same routing reason.
Actual
Expected
The QuestionPrompt reply/reject should route to the session/question directory instance, remove the pending question, and dismiss the prompt.
Additional diagnostic evidence
After the prompt is stuck, the pending question is not visible from the default/current directory instance:
curl http://127.0.0.1:41003/question # []It is still visible from the original project directory instance:
Manually replying to the pending request with the correct directory works:
After that manual reply,
/question?directory=...returns[]and the TUI resumes. This suggests the Question service is healthy and the failure is in the TUI/SDK routing forquestion.reply/question.reject.Likely relevant code path:
packages/opencode/src/cli/cmd/tui/routes/session/question.tsxcallssdk.client.question.reply({ requestID, answers })without passing a directory/workspace override.API-level repro evidence
I also reproduced the underlying routing failure at the HTTP API level on
v1.15.13/385cb694419f98103af0e8fc6187ddcbcbb6eecb, without relying on manual TUI timing. I used a container only to isolate the test environment; Docker is not required for the repro. The paths below are example directories.Trigger a question through the session message endpoint while explicitly routing the prompt to the project directory:
Before replying, the pending question exists only in the project directory instance:
Then reply without
directory, matching whatQuestionPromptcurrently does:However, the real pending request is still present in the project directory instance:
Replying with the correct directory clears it:
So the failure can be hidden by a successful HTTP response from the wrong route/instance: the directory-less
replyreturns200 true, but it does not clear the pending question in the instance that owns the request. This matches the TUI symptom where the selected option gets a green checkmark but the question prompt remains stuck.Screenshot and/or share link
N/A
Operating System
Debian GNU/Linux 13 (trixie), Linux x86_64
Terminal
TUI/PTY; also observed in a normal terminal.