No response to user input #3846

Activity

1. jgordijn

   added

   bugSomething isn't workingSomething isn't working

   on Nov 3, 2025
2. github-actions

   added

   opentuiThis relates to changes in v1.0, now that opencode uses opentuiThis relates to changes in v1.0, now that opencode uses opentui

   on Nov 3, 2025
3. github-actions commented on Nov 3, 2025

   

   github-actionsBot

   on Nov 3, 2025 – with GitHub Actions

   Contributor

   More actions

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

   • bug: sometimes clangd lsp hangs #3598: LSP hanging causes users to get stuck in working state
   • working getting stuck and double esc not exiting #1418: OpenCode getting stuck on 'working' with double ESC not working
   • Commands lock opencode #3154: Commands can lock OpenCode indefinitely
   • Output starts to slow to a crawl #3822: UI output slows to a crawl causing responsiveness issues

   Feel free to ignore if none of these address your specific case.
4. jgordijn commented on Nov 3, 2025

   

   jgordijn

   on Nov 3, 2025

   Author

   More actions

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

   self-assigned this

   on Nov 4, 2025
6. thdxr commented on Nov 4, 2025

   

   thdxr

   on Nov 4, 2025 – with Linear

   Member

   More actions

   can you produce a video?
7. jgordijn commented on Nov 4, 2025

   

   jgordijn

   on Nov 4, 2025

   Author

   More actions

   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.

   no_response.mov

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

   theme_switcher.mov
8. jgordijn commented on Nov 4, 2025

   

   jgordijn

   on Nov 4, 2025

   Author

   More actions

   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
9. jgordijn

   changed the title [-]No repsonse to user input[/-] [+]No response to user input[/+] on Nov 4, 2025
10. marklise commented on Dec 5, 2025

    

    marklise

    on Dec 5, 2025

    More actions

    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
11. marklise commented on Dec 6, 2025

    

    marklise

    on Dec 6, 2025

    More actions

    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.
12. thdxr

    closed this as completedon Mar 25, 2026