Skip to content

[FEATURE]: No way to start SDK server without loading user MCP servers #20072

Closed as not planned
Closed as not planned
[FEATURE]: No way to start SDK server without loading user MCP servers#20072
Assignees
rekram1-node

Description

@kud
kud
opened on Mar 30, 2026
  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

When using @opencode-ai/sdk to embed OpenCode programmatically (e.g. a CLI tool that makes a one-shot model call), the server always loads all MCP servers from the user's ~/.config/opencode/opencode.jsonc at startup. There is currently no way to prevent this.

Why this matters

The GitHub Copilot API hard-caps tool count at 128 tools. A power user with many MCP servers can easily exceed this, causing a HTTP 400 error from the API:

Error: 400 Bad Request — tools count exceeds maximum allowed (128)

What was tried

1. Passing enabled: false via OPENCODE_CONFIG_CONTENT

const client = await createOpencode({
  config: JSON.stringify({
    mcp: {
      github: { enabled: false },
      playwright: { enabled: false },
      // ... all user MCPs
    }
  })
})

Result: All MCPs still connect at startup. The enabled: false config is silently ignored.

2. Disconnecting after startup (current workaround)

const client = await createOpencode({ ... })

const statusResult = await client.mcp.status()
const mcpNames = Object.keys(statusResult.data ?? {})
await Promise.all(mcpNames.map(name => client.mcp.disconnect({ name })))

const session = await client.session.create({ ... })

This works (MCPs end up "status": "disabled"), but is wasteful — every MCP connects then immediately disconnects on every invocation.

Requested change

Please add one of:

  1. A startup option — e.g. createOpencode({ mcp: false }) to skip loading user MCPs entirely
  2. Fix enabled: false in config — honour it at startup when passed via OPENCODE_CONFIG_CONTENT
  3. A noMcp flag on the server or session level

Note on potential duplicates: #17605 and #4525 address project-level MCP overrides. This request is specifically about SDK/embedded use — programmatic consumers that should not inherit the user's global MCP config at all.

Environment

  • @opencode-ai/sdk v1.3.7
  • API: @opencode-ai/sdk/v2
  • Provider: github-copilot/gpt-4.1

Activity

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

  3. github-actions commented on Mar 30, 2026

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

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • The issue does not use one of the required templates (Bug Report, Feature Request, or Question). Feature requests must use the Feature Request template, which requires a verification checkbox and a proper description field. The title should also start with [FEATURE]: instead of [SDK].

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.

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

    If you believe this was flagged incorrectly, please let a maintainer know.

  4. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Mar 30, 2026
  5. kud
    changed the title [-][SDK] MCP servers cannot be disabled at startup — no way to start server without loading user MCPs[/-] [+][FEATURE]: No way to start SDK server without loading user MCP servers[/+] on Mar 30, 2026
  6. github-actions
    removed
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Mar 30, 2026

  7. kud commented on Mar 30, 2026

    @kud
    kud
    on Mar 30, 2026
    Author

    Workaround (until this is fixed in the SDK)

    For anyone hitting this, here's what we ended up doing in @kud/ai-conventional-commit-cli:

    Before calling createOpencode(), temporarily redirect XDG_CONFIG_HOME to a temp directory containing a minimal opencode/config.json with an empty MCP section. Since the SDK spawns opencode serve with { ...process.env } at call time, the child process picks up the isolated config and starts with zero MCP servers.

    import { mkdirSync, writeFileSync } from 'node:fs';
import { join } from 'node:path';
import { tmpdir } from 'node:os';

// Create isolated config: <tmp>/aicc-<pid>/opencode/config.json
const isolatedDir = join(tmpdir(), `aicc-${process.pid}`, 'opencode');
mkdirSync(isolatedDir, { recursive: true });
writeFileSync(join(isolatedDir, 'config.json'), '{"mcp":{}}');

const originalXDG = process.env.XDG_CONFIG_HOME;
process.env.XDG_CONFIG_HOME = join(tmpdir(), `aicc-${process.pid}`);

try {
  opencode = await createOpencode({ signal, port });
} finally {
  if (originalXDG === undefined) delete process.env.XDG_CONFIG_HOME;
  else process.env.XDG_CONFIG_HOME = originalXDG;
}

    This works on macOS and Linux where opencode respects XDG_CONFIG_HOME. It's a bit of a hack but eliminates the overhead of connecting/disconnecting all user MCP servers on every CLI invocation.

  8. iMaxTomas commented on Apr 12, 2026

    @iMaxTomas
    iMaxTomas
    on Apr 12, 2026

    I ran into the same fundamental problem from the end-user / TUI side and did a deep-dive into the root causes. One significant finding: chrome-devtools and morphllm-fast-apply are spawned by the opencode binary itself rather than from user configuration, so even isolating XDG_CONFIG_HOME into an empty opencode.json ({"mcp":{}}) does not prevent these built-in MCPs from loading when running the full TUI or desktop app.

    This means the XDG_CONFIG_HOME workaround you documented works for SDK callers, but end users still have no supported way to start a lean OpenCode session with zero MCP overhead.

    I've submitted a feature request (#22188) asking for an official kill switch (e.g. disabled_mcp_servers array or respecting enabled: false for built-ins). It references your workaround as the current best option for the SDK path, but highlights that a broader fix is needed for the binary-bundled defaults.

  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