[Bug]: OpenCode external-server threads receive mandatory instructions for unavailable T3 PR tools #35588

Before submitting

• I searched existing issues and did not find a duplicate of the instruction mismatch reported here.
• I included enough detail to reproduce or investigate the problem.

Summary

OpenCode threads connected through a configured serverUrl receive mandatory PR-linking/watching instructions even though T3 intentionally does not register its MCP server for that connection. The agent is told to call tools that do not exist.

This report is not a request to enable automatic MCP registration for external servers. I found #19276 and understand the credential-sharing/trust boundary described there. The fault here is that the injected instructions do not reflect that intended absence of tools. #22369 concerns unsupported VCS/CI integrations; this reproduces without any T3 MCP connection at all.

Area

apps/server — OpenCode provider adapter / shared runtime instructions.

Steps to reproduce

1. Run an existing OpenCode 2 server on the same machine as T3, independently of T3.
2. Configure the T3 OpenCode provider's Server URL to point to it (the observed setup uses http://127.0.0.1:49374) and authenticate as needed.
3. Open an OpenCode thread in T3 and ask the agent to inspect its available T3 PR tools.
4. Compare the model-visible tool catalog with the session's t3-code instruction entry. OpenCode's read APIs can also confirm this: GET /api/mcp with the thread's location[directory], and GET /api/experimental/session/<sessionID>/instructions/entries.

Expected behavior

When T3 intentionally withholds its MCP connection, it should not instruct the agent to call link_pull_request, link_pull_requests, watch_pull_request, or unwatch_pull_request, or impose a waiting workflow that requires those absent tools.

Keep the external-server trust boundary unchanged. Omit or appropriately qualify the PR-tool instructions when the integration is unavailable, as is already done for the MCP-dependent orchestration instructions.

Actual behavior

The session receives <context key="t3-code"> containing <runtime_info> and <pull_request_linking>, including these unconditional requirements:

Link each PR you create, take over, or push to: link_pull_request, or link_pull_requests for several, full URL, every stack layer, as your next call.

Call watch_pull_request when asked to monitor or babysit [...] For PR waits, no sleep, loops, gh --watch, Monitor or ScheduleWakeup.

However, no T3 server is registered and none of those tools are available. The agent cannot comply. The contradictory context initially made this look like a broken MCP connection/forwarding path, rather than intentional withholding.

Live evidence

Sanitized diagnostic summary from the affected session:

OpenCode server version: 2.2.7
T3 MCP entry in GET /api/mcp for the thread location: absent
T3 tools in the complete Code Mode catalog: absent
Instruction entry key: t3-code
Contains runtime_info: true
Contains pull_request_linking: true
Contains MCP-dependent orchestration guidance: false
T3 /mcp endpoint: running; unauthenticated request returns HTTP 401

The problem persisted across ordinary user turns. This is not the first-turn catalog timing issue addressed by #35084.

Source evidence

Source inspected at cf82fb858458be25daeccf811f213d6ed73979f1:

• OpenCode2Server.ts:138–152: any configured Server URL selects an external: true connection, including loopback.
• adapter.ts:4058–4062: connection.external intentionally prevents T3 MCP registration.
• adapter.ts:4103–4115: buildRuntimeInstructions(...) is still added regardless of mcpAvailable, while orchestration guidance is conditioned on availability.
• runtimeInstructions.ts:23–26: PR instructions are appended unless pullRequestLinking is explicitly false. The OpenCode caller does not set it false in this path.

Impact

Minor bug or occasional failure — mandatory instructions cannot be followed in every thread using this supported connection mode, and they obscure the intended reason the tools are absent.

Version or commit

Running T3 server and desktop client: 0.1.10-nightly.20261112.4580.
Source inspection: cf82fb858458be25daeccf811f213d6ed73979f1.

Environment

macOS / Apple Silicon; T3 nightly desktop client connected to a local T3 server; OpenCode 2.2.7 running as an existing local service; provider/model github-copilot/gpt-6.1-sol.

Workaround

No workaround was applied during this investigation. Letting T3 manage its own OpenCode server should avoid the external-connection path, but requires giving up the configured shared server. A manual OAuth MCP connection is another possible approach; it has not been tested here and does not remove the need for accurate instructions when no connection exists.