mcp: v2 Atlassian and GitHub sessions rate-limit after idle periods

[stevoland]

Summary

After opencode2 has been idle for a significant amount of time, the Atlassian
and GitHub Streamable HTTP MCP connections start returning rate-limit errors,
even though no MCP tools were explicitly called during the idle period.

This did not occur with OpenCode v1 using the same MCP integrations.

Environment

• opencode version: opencode2 v0.0.0-beta-17639
• OS: macOS Darwin 25.6.0, arm64
• Terminal: Ghostty (TERM=xterm-256color, COLORTERM=truecolor)
• Shell: /bin/zsh
• Install/channel: beta
• Active plugins: /Users/stephen.collings/workspace/github.com/eeveebank/nwb/opencode-plugins/v2/dist/boxedcode.js

Reproduction

1. Start opencode2 with the Atlassian and GitHub remote MCPs configured.
2. Do not explicitly call any Atlassian or GitHub MCP tools.
3. Leave the OpenCode session idle for a significant period.
4. Attempt to use either the Atlassian or GitHub MCP.

Expected Behavior

The MCP connections should remain usable while the session is idle, without
consuming requests or entering a rate-limited state.

Actual Behavior

The MCP calls fail with Streamable HTTP rate-limit errors:

Atlassian Streamable HTTP error:
Error POSTing to endpoint: {"jsonrpc":"2.0","error":{"code":-32000,"message":"Too many requests. Please retry later."}}

GitHub Streamable HTTP error:
Error POSTing to endpoint: too many requests

Both integrations are affected after the idle period.

Additional Context

The issue appears after a significant period with no explicit MCP tool calls.
The exact idle duration has not yet been measured.

The same setup did not exhibit this behavior under OpenCode v1.

[github-actions]

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

• server: auth and MCP connections fail after idle period #43444: MCP and auth connections fail after idle periods (similar idle-period MCP failure, different symptom — auth errors and ENOTFOUND vs rate-limit errors)

If your issue is distinct (specifically rate-limiting from background keep-alive requests rather than reconnection failures), please add a note clarifying that so maintainers can track them separately.

[stevoland]

If your issue is distinct (specifically rate-limiting from background keep-alive requests rather than reconnection failures), please add a note clarifying that so maintainers can track them separately

well ok, sounds different son