anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

No response to user input #2544

New Issue
Open
opened 2026-02-16 17:36:09 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 17:36:09 -05:00
Owner
Copy Link
Copy Source

Originally created by @jgordijn on GitHub (Nov 3, 2025).

Originally assigned to: @thdxr on GitHub.

Description

I’m trying to use open code more frequently because I really appreciate the work you put into it!

However, I've encountered an issue during my sessions: sometimes the user interface appears to be stuck and becomes unresponsive. Sometimes it is stuck on a prompt and when I press "enter", nothing seems to happen. In some occasions I just need to wait 5-10 seconds and it continues, but other times it will not do anything and I need to kill the process. I will not even listen to <ESC>, <CTRL>-C. <CTRL>-Z. So it is really stuck.

I can see the progress indicator moving over the model, so I know it’s not completely frozen.

OpenCode version

1.0.15

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

Mac

Terminal

Ghostty

Originally created by @jgordijn on GitHub (Nov 3, 2025). Originally assigned to: @thdxr on GitHub. ### Description I’m trying to use open code more frequently because I really appreciate the work you put into it! However, I've encountered an issue during my sessions: sometimes the user interface appears to be stuck and becomes unresponsive. Sometimes it is stuck on a prompt and when I press "enter", nothing seems to happen. In some occasions I just need to wait 5-10 seconds and it continues, but other times it will not do anything and I need to kill the process. I will not even listen to `<ESC>`, `<CTRL>-C`. `<CTRL>-Z`. So it is really stuck. I can see the progress indicator moving over the model, so I know it’s not completely frozen. ### OpenCode version 1.0.15 ### Steps to reproduce _No response_ ### Screenshot and/or share link _No response_ ### Operating System Mac ### Terminal Ghostty
yindo added the opentuibug labels 2026-02-16 17:36:09 -05:00
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 3, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #3598: LSP hanging causes users to get stuck in working state
  • #1418: OpenCode getting stuck on 'working' with double ESC not working
  • #3154: Commands can lock OpenCode indefinitely
  • #3822: UI output slows to a crawl causing responsiveness issues

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 3, 2025): This issue might be a duplicate of existing issues. Please check: - #3598: LSP hanging causes users to get stuck in working state - #1418: OpenCode getting stuck on 'working' with double ESC not working - #3154: Commands can lock OpenCode indefinitely - #3822: UI output slows to a crawl causing responsiveness issues Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@jgordijn commented on GitHub (Nov 3, 2025):

I got it to listen to <CTRL>-p, but I cannot really do much as it seems still unresponsive

@jgordijn commented on GitHub (Nov 3, 2025): I got it to listen to `<CTRL>-p`, but I cannot really do much as it seems still unresponsive
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Nov 3, 2025):

can you produce a video?

@thdxr commented on GitHub (Nov 3, 2025): can you produce a video?
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@jgordijn commented on GitHub (Nov 4, 2025):

Here is a screen recording. During this recording I pressed d and <ESC>, but it does not respond. You see that when I press <CTRL>-p, it does react to that.

https://github.com/user-attachments/assets/1682e3c4-a80d-46c0-84eb-7e005ea8a2ea

The second video is the same session. Theme switching get's the session stuck/really slow

https://github.com/user-attachments/assets/1c3a1707-faea-48f3-bf93-11275b3975f4

@jgordijn commented on GitHub (Nov 4, 2025): Here is a screen recording. During this recording I pressed `d` and `<ESC>`, but it does not respond. You see that when I press `<CTRL>-p`, it does react to that. https://github.com/user-attachments/assets/1682e3c4-a80d-46c0-84eb-7e005ea8a2ea The second video is the same session. Theme switching get's the session stuck/really slow https://github.com/user-attachments/assets/1c3a1707-faea-48f3-bf93-11275b3975f4
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@jgordijn commented on GitHub (Nov 4, 2025):

I noticed that I am able to create a new session. This new session is working, so it seems to be related to the specific session

@jgordijn commented on GitHub (Nov 4, 2025): I noticed that I am able to create a new session. This new session is working, so it seems to be related to the specific session
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@marklise commented on GitHub (Dec 5, 2025):

Similar Issue - Permission Loop Causing Input Unresponsiveness

I encountered a very similar issue where the input box became completely unresponsive.

Symptoms:

  • Input field won't accept any text input
  • Tab key works (can switch between plan/build modes)
  • Process appears running but UI is stuck
  • Eventually need to kill the process

Environment:

  • OpenCode Version: 1.0.134
  • OS: Linux (NixOS)
  • Terminal: xterm-256color
  • Display: Wayland

Technical Details:

Process State:

  • Main process: PID 16760, state S (sleeping on do_epoll_wait)
  • 20 threads, 478MB RSS
  • Very high voluntary context switches (1,350,043) indicating excessive waiting
  • CPU time: 15 minutes accumulated
  • YAML language server subprocess also running

Root Cause Found in Logs:

Analyzing ~/.local/share/opencode/log/ revealed a permission retry loop:

  1. At 2025-12-05T22:47:28, user granted permission per_af060bdd2001LMBYDg2Bbsjuwk with response=once
  2. 90 seconds later at 2025-12-05T22:48:58, the same permission was requested again
  3. Permission was rejected, but kept being re-requested repeatedly
  4. Loop continued for over 5 minutes with requests at increasing intervals
  5. UI input became completely unresponsive during this loop

Log excerpt showing the loop:

INFO  2025-12-05T22:47:28 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=once response
...
INFO  2025-12-05T22:48:58 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response
INFO  2025-12-05T22:48:59 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response
INFO  2025-12-05T22:49:01 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response
... (continues repeatedly)

Theory:

It appears that when a permission is granted as "once", there's a bug where:

  1. The permission gets re-requested after some condition/timeout
  2. The UI tries to prompt for the same permission again
  3. It gets auto-rejected (since it was already answered)
  4. This creates a retry loop that blocks the input system
  5. The input field becomes unresponsive even though the process isn't fully hung

This matches the symptoms reported here where the UI becomes unresponsive but some functions (like Ctrl-P in the original report, tab switching in my case) still work, suggesting the main event loop is running but the input handling is blocked waiting on permission resolution.

Suggestion:

The permission system should either:

  • Not re-request permissions that were already granted as "once" within the same session
  • Have a maximum retry limit and fail gracefully
  • Not block the input system while waiting for permission responses
@marklise commented on GitHub (Dec 5, 2025): ## Similar Issue - Permission Loop Causing Input Unresponsiveness I encountered a very similar issue where the input box became completely unresponsive. ### Symptoms: - Input field won't accept any text input - Tab key works (can switch between plan/build modes) - Process appears running but UI is stuck - Eventually need to kill the process ### Environment: - **OpenCode Version:** 1.0.134 - **OS:** Linux (NixOS) - **Terminal:** xterm-256color - **Display:** Wayland ### Technical Details: **Process State:** - Main process: PID 16760, state S (sleeping on `do_epoll_wait`) - 20 threads, 478MB RSS - Very high voluntary context switches (1,350,043) indicating excessive waiting - CPU time: 15 minutes accumulated - YAML language server subprocess also running **Root Cause Found in Logs:** Analyzing `~/.local/share/opencode/log/` revealed a **permission retry loop**: 1. At `2025-12-05T22:47:28`, user granted permission `per_af060bdd2001LMBYDg2Bbsjuwk` with `response=once` 2. 90 seconds later at `2025-12-05T22:48:58`, the **same permission was requested again** 3. Permission was rejected, but **kept being re-requested repeatedly** 4. Loop continued for over 5 minutes with requests at increasing intervals 5. UI input became completely unresponsive during this loop **Log excerpt showing the loop:** ``` INFO 2025-12-05T22:47:28 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=once response ... INFO 2025-12-05T22:48:58 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response INFO 2025-12-05T22:48:59 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response INFO 2025-12-05T22:49:01 service=permission permissionID=per_af060bdd2001LMBYDg2Bbsjuwk response=reject response ... (continues repeatedly) ``` ### Theory: It appears that when a permission is granted as "once", there's a bug where: 1. The permission gets re-requested after some condition/timeout 2. The UI tries to prompt for the same permission again 3. It gets auto-rejected (since it was already answered) 4. This creates a retry loop that blocks the input system 5. The input field becomes unresponsive even though the process isn't fully hung This matches the symptoms reported here where the UI becomes unresponsive but some functions (like Ctrl-P in the original report, tab switching in my case) still work, suggesting the main event loop is running but the input handling is blocked waiting on permission resolution. ### Suggestion: The permission system should either: - Not re-request permissions that were already granted as "once" within the same session - Have a maximum retry limit and fail gracefully - Not block the input system while waiting for permission responses
yindo commented 2026-02-16 17:36:09 -05:00
Author
Owner
Copy Link
Copy Source

@marklise commented on GitHub (Dec 5, 2025):

Additional notes, I think it's very likely my previous comment outlines the issue as when I finally kill the process, restart opencode and bring the session back, it actually did work in behind the scenes.

@marklise commented on GitHub (Dec 5, 2025): Additional notes, I think it's very likely my previous comment outlines the issue as when I finally kill the process, restart opencode and bring the session back, it actually did work in behind the scenes.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2544
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?