Description
When continuing an existing local session from a different current working directory, the Question tool UI can hang after selecting an option.
The 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>
-
Ask the assistant to call the Question tool with one single-choice question (multiple: false).
-
When the question UI appears, compare the pending questions:
curl http://127.0.0.1:41003/question
# []
curl "http://127.0.0.1:41003/question?directory=%2Fhome%2Fuser%2Fprojects%2Fopencode-fix"
# contains the pending question request
-
Press Enter in the TUI to select the highlighted option.
Actual
- The selected option gets a green checkmark.
- The question UI does not dismiss.
- The pending request remains under
?directory=/home/user/projects/opencode-fix.
- Esc/Ctrl-C do not recover the TUI; the user has to close the terminal.
Observed after pressing Enter:
curl "http://127.0.0.1:41003/question?directory=%2Fhome%2Fuser%2Fprojects%2Fopencode-fix"
# still returns the same pending request id
Expected
The QuestionPrompt reply should route to the session/question directory instance, remove the pending question, and dismiss the prompt.
Additional diagnostic evidence
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 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:Ask the assistant to call the Question tool with one single-choice question (
multiple: false).When the question UI appears, compare the pending questions:
Press Enter in the TUI to select the highlighted option.
Actual
?directory=/home/user/projects/opencode-fix.Observed after pressing Enter:
Expected
The QuestionPrompt reply should route to the session/question directory instance, remove the pending question, and dismiss the prompt.
Additional diagnostic evidence
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.