MCP tool completes successfully but session never resumes or finalizes in serve/web mode #22156

Description

In serve/web mode, an MCP tool can complete successfully but the session never resumes to the next assistant turn and never finalizes a user-visible answer.

This is not the same as a pending permission or pending question state.

In our repro, the tool call finishes successfully, /permission returns [], /question returns [], and the session remains stuck after the completed tool part.

This was reproduced in a Build-embedded OpenCode deployment behind a launcher/reverse proxy, but the stuck behavior appears to be in the OpenCode orchestration/runtime path after a successful MCP tool result.

Representative failing flow:

• User prompt: what git orgs do I have access to?
• Agent follows prompt guidance and calls gitea_gitea_user_current
• Tool returns successfully with the current user login
• No pending permission request remains
• No pending question request remains
• No final assistant continuation appears

Representative successful tool output:

{
  "id": 1,
  "login": "gitea_admin",
  "full_name": "",
  "email": "admin@thepeoples.dev",
  "avatar_url": "https://git.thepeoples.dev/avatars/257dfd123bbdae720b16c78fe50454c0"
}

We also reproduced a similar shape on a generic bash-tool prompt after switching bash permissions to allow: the tool executes successfully, but the assistant still may not continue to a final answer.

Plugins

Build-local plugins plus a local MCP server:

• secret-guard.js
• workspace-shell.js
• local Gitea MCP server (gitea-mcp-tool)

OpenCode version

1.3.15

Steps to reproduce

1. Run OpenCode in serve/web mode.
2. Configure a local MCP server for Gitea.
3. Create a session using a normal tool-capable agent.
4. Send a prompt like: what git orgs do I have access to?
5. Observe that OpenCode calls gitea_gitea_user_current and receives a successful result.
6. Query the session state and auxiliary endpoints.
7. Observe:
   • the MCP tool part is marked completed
   • /permission returns []
   • /question returns []
   • no follow-up assistant answer is generated

Additional repro signal:

1. Configure bash permission so shell calls do not block on approval.
2. Prompt: Use tools to tell me what files are in the current directory.
3. Observe the bash tool call completes successfully.
4. The assistant may still fail to continue to a final natural-language answer.

Screenshot and/or share link

No share link. We validated this through the serve/web session endpoints directly:

• GET /session/{id}/message?limit=100
• GET /permission
• GET /question

Representative session IDs from our environment:

• ses_27dae160affelgEU106T8voc7d (Gitea repro)
• ses_27dae1677ffeP91bFZpxOrhhSW (generic tool repro after bash allow)

Operating System

Linux (Kubernetes pod on Fedora CoreOS host)

Terminal

Web UI / serve mode behind a reverse proxy launcher