Skip to content

Agent tool calls execute silently — UI frozen, no progress, exploration loop runs unchecked #18723

New issue
New issue
Closed as not planned
Closed as not planned
Agent tool calls execute silently — UI frozen, no progress, exploration loop runs unchecked#18723
Assignees
jlongster

Description

@zengzheqing
zengzheqing
opened on Mar 23, 2026

Summary

When using OpenCode v1.3.0 with an OpenAI-compatible provider, the agent frequently enters a state where it runs tool calls (file reads, rg searches) in the background but the UI shows absolutely nothing — no spinner, no tool output, no stage report, no progress indicator. The session appears completely frozen.

The root cause appears to be uncontrolled exploration: the agent expands its search scope without converging, never reports intermediate progress, and never sends results back to the LLM. It's a workflow/exploration control problem, not a network or model issue.

Core Problem: Exploration Runs Unchecked

The agent's open-ended exploration mode has three compounding failures:

  1. Over-expansion: When given a task requiring multi-file research, the agent keeps broadening its search (read file A → grep for references → read file B → grep again...) without any convergence mechanism
  2. No stage reporting: During this exploration, the UI renders nothing. The user has zero visibility into what the agent is doing or how far it has progressed
  3. No convergence/timeout: The exploration loop has no circuit breaker — it will run indefinitely until the user kills it with Ctrl+C

Environment

  • OpenCode: v1.3.0 (macOS arm64)
  • Provider: OpenAI-compatible API via local gateway (http://127.0.0.1:18081/v1)
  • Model: gpt-5.4 with reasoning: true, effort xhigh
  • OS: macOS 15.4 (Darwin 25.3.0, arm64)

Evidence

While the UI shows nothing, background processes are clearly active:

$ ps aux | grep opencode
zengzheqing  47704  13.6  1.1  ...  opencode -s ses_...
zengzheqing  53854   0.0  0.0  ...  rg -nH --hidden --regexp "gatewayctl|..." --glob *.{sh,zsh,py,md,json,toml} ...

The gateway shows zero active connections — OpenCode is not calling the LLM:

$ lsof -i :18081
COMMAND     PID   FD  TYPE  NODE NAME
codex-gat 56142  11u  IPv6  TCP  *:18081 (LISTEN)
# No ESTABLISHED connections

This confirms the agent is stuck in a local tool-call loop: executing rg / file reads but never returning to the LLM and never rendering anything to the user.

Key Comparison: Codex CLI Does NOT Have This Issue

Same model (gpt-5.4), same reasoning effort (xhigh), same gateway, same project — Codex CLI completes identical tasks without freezing. Every tool call is displayed, progress is streamed, exploration converges. This rules out model behavior and network issues entirely.

Reproduction

  1. Configure OpenCode with an OpenAI-compatible provider
  2. Open a project with large files (400+ line scripts, multiple interconnected source files)
  3. Give an open-ended task (e.g., "audit the lifecycle management scripts and fix credential loading")
  4. Wait — UI will freeze after the first model response triggers tool calls
  5. Observed: session frozen for 30+ minutes with zero UI output
  6. ps aux shows rg processes spawned by OpenCode actively running

Workaround

Ctrl+C → restart session → type continue → session resumes until it freezes again.

Expected Behavior

  1. Tool calls rendered in real-time — show what file is being read, what grep is running
  2. Stage/progress reporting — periodic summaries of what the agent has found so far
  3. Exploration convergence — after N tool calls or M seconds without LLM interaction, the agent should consolidate findings and return to the LLM
  4. Visible activity indicator — at minimum a spinner showing the agent is working

Actual Behavior

  1. UI is completely blank — no spinner, no tool output, nothing
  2. Background tool processes (rg, file reads) are running
  3. No LLM API calls are being made
  4. Agent never converges — will loop indefinitely
  5. Only recovery is Ctrl+C + manual restart

Activity

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

  3. github-actions commented on Mar 23, 2026

    @github-actions
    github-actionsBot
    on Mar 23, 2026 – with GitHub Actions
    Contributor

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

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

  4. zengzheqing commented on Mar 23, 2026

    @zengzheqing
    zengzheqing
    on Mar 23, 2026
    Author

    Follow-up: local isolation pass confirms this is NOT a gateway/wrapper issue

    I did a deep local isolation pass and fixed multiple gateway-side integration issues, but they do not explain the "gpt-5.4 xhigh feels frozen / no progress for a very long time" incidents described above.

    Locally validated

    • Real request → fulfill → restart on the local gateway succeeds end-to-end
    • OpenCode wrapper works: ./scripts/opencodegw.sh run 'Reply with exactly OK.' returns OK
    • Gateway health recovers correctly after restart (/readyz OK, new PID, pending request cleared)

    So the earlier symptom is different from wrapper/restart failure

    • Not immediate failure or disconnect (those were separately identified and fixed)
    • More like a long silent phase with no visible progress
    • Happened specifically during open-ended, tool-heavy exploration flows

    Current suspicion: runtime/UX progress-reporting gap under xhigh + multi-tool exploration

    Potential maintainer directions:

    • Inspect heartbeat/progress updates during xhigh + multi-tool exploration — are they too weak or missing during long search phases?
    • Inspect whether long search phases suppress user-visible updates entirely
    • Inspect whether aborted/interrupted search branches can leave the session appearing "alive but silent"
    • Inspect whether xhigh materially changes tool orchestration cadence without enough UI heartbeat to match

  5. zengzheqing commented on Mar 23, 2026

    @zengzheqing
    zengzheqing
    on Mar 23, 2026
    Author

    More local isolation results:

    • OpenCode through the local gateway wrapper is able to complete one-shot runs successfully
    • forcing defaultVariant = xhigh also works for one-shot runs
    • so this does NOT look like a simple wrapper/gateway/xhigh-config failure

    But:

    • as soon as the task becomes even mildly open-ended and tool/search-driven, OpenCode can go into a long silent phase and eventually time out
    • this happened even on small repo-local tasks like “find the file that renders OpenCode gateway config”
    • when the task is tightly constrained to a specific file read, it can complete

    This makes the issue look more like:

    • OpenCode runtime/tool-orchestration/progress-heartbeat problem during open-ended exploration
    • not primarily a local gateway integration problem

  6. zengzheqing commented on Mar 23, 2026

    @zengzheqing
    zengzheqing
    on Mar 23, 2026
    Author

    I ran a more controlled comparison on the same small open-ended repo-search task:

    Task:

    • “Find the filename in this repo that renders OpenCode gateway config. Answer with the filename only.”

    Results:

    • default / non-explicit-xhigh path: timed out after entering repo search
    • explicit defaultVariant = xhigh path: also timed out

    This makes the issue look less like “xhigh-specific freeze” and more like:

    • OpenCode open-ended tool/search exploration can enter a long silent phase and time out
    • xhigh may amplify it, but the underlying issue may be exploration/runtime/progress related rather than xhigh-only

  7. zengzheqing commented on Mar 23, 2026

    @zengzheqing
    zengzheqing
    on Mar 23, 2026
    Author

    Additional isolation result:
    I split the behavior into two cases under explicit xhigh:

    1. pure reasoning / no repo search
    • completed successfully and quickly
    • example: reversing a simple string returned in a few seconds
    1. repo-search / tool-driven task
    • timed out
    • no useful final answer within the timeout window

    So this looks less like “xhigh reasoning itself is broken” and more like:

    • OpenCode’s open-ended tool/search exploration path can enter a long silent stall
    • xhigh may amplify it, but the underlying issue seems more related to tool-heavy exploration / progress heartbeat / search orchestration than to pure reasoning alone

    I also observed a live long-running session that:

    • stayed connected to the gateway
    • remained alive for over an hour
    • but had no active child search processes at observation time
    • which looked more like a silent stalled state than active progress
  8. thdxr
    assigned
    jlongster
    and unassigned
    thdxr
    on Apr 26, 2026
  9. thdxr
    removed
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  10. github-actions commented on Jul 3, 2026

    @github-actions
    github-actionsBot
    on Jul 3, 2026 – with 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.

  11. github-actions
    closed this as not plannedon Jul 3, 2026
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