Skip to content

Agent hangs indefinitely when using opencode serve + opencode attach if any permission is set to "ask" #16367

Closed as not planned

Description

@shaugupt

Description

When running opencode serve and connecting remotely via opencode attach, the agent enters an infinite processing loop and never returns a response. The TUI connects and displays fine, but sending any message causes the agent to spin forever.

Version

1.2.20

Steps to Reproduce

  1. Start a headless server: opencode serve --hostname 0.0.0.0 --port <port>
  2. From a remote machine, attach to it: opencode attach http://<host>:<port>
  3. Send any message to the agent in the remote TUI

Expected Behavior

The agent processes the message and returns a response, same as when running opencode locally.

Actual Behavior

The agent enters an infinite processing loop and never completes. The remote TUI shows the agent as permanently "thinking". No error is shown.

Root Cause

The default permission for doom_loop (and external_directory) is "ask", which triggers an interactive approval prompt in the TUI. When running in headless server mode (opencode serve), those prompts have no UI to surface them through — and opencode attach does not relay permission prompts from the server to the remote client. The server silently waits for input that never arrives, causing the agent to hang indefinitely.

This can be confirmed in the server logs: the agent loops through tool resolution steps repeatedly without ever completing or erroring.

Workaround

Create an opencode.json config (e.g. at ~/.opencode/opencode.json or the project-level equivalent) that sets doom_loop and external_directory to "allow":

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "allow",
    "doom_loop": "allow",
    "external_directory": "allow"
  }
}

Then restart the server. The agent will process messages normally.

Suggested Fix

opencode serve should either:

  • Automatically override "ask" permissions to "allow" when running in headless mode (since there is no interactive terminal to answer prompts), or
  • Relay permission prompts to the attached remote client's TUI so they can be answered there, or
  • Warn at startup that certain permissions are set to "ask" which will cause hangs in headless mode

Additional Context

The issue is specific to the opencode serve + opencode attach workflow. Running opencode locally (non-headless) is unaffected.

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 6, 2026
  2. github-actions commented on Mar 6, 2026

    @github-actions
    Contributor

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

  3. dhowe commented on Mar 22, 2026

    @dhowe

    Still seeing this issue, and the workaround mentioned by @shaugupt doesn't fix it

  4. namdien177 commented on Apr 19, 2026

    @namdien177

    I recently faced this issue and I noticed (and also tested by removing it afterward) that having this in the opencode.json configuration just cause everything to slow/hang/not responsive. Removing it makes my OpenCode run fast again.

    my innocent mind just want to allow opencode to read download directory freely 🥲

      "permission": {
        "external_directory": {
          "~/Downloads/**": "allow"
        }
      },
    
  5. assigned and unassigned on Apr 26, 2026
  6. removed
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  7. oleg-bk commented on May 27, 2026

    @oleg-bk

    For headless/server mode, ask probably needs to become an explicit pending state with an approval channel, not an in-process prompt.

    If no approval channel is attached, failing closed with a structured error seems safer than hanging and safer than forcing users to change config to allow.

    The useful fields for a pending permission are tool/action, normalized target, session id, requested scope, and a resume token. That would let attach/TUI/web clients render the same pending decision and resume once approved or denied.

  8. ashish16052 commented on Jul 9, 2026

    @ashish16052

    For API clients, the server-side flow that has worked for me is to handle permission events explicitly.

    Listen for permission.asked, show/decide the permission in the host app, then POST the reply back to the permission endpoint.

    Example:

    https://github.com/ashish16052/opencode-runtime/blob/main/docs/streaming.md#handle-permission-requests

    This does not fix the attach/TUI relay issue directly, but it may be useful as the expected headless/API behavior.

  9. github-actions commented on Sep 8, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions