Skip to content

Add multi-account support for client-side account switching #1940

@drtootsie

Description

@drtootsie

Is your feature request related to a problem? Please describe.

Users with multiple GitHub accounts (e.g., work + personal, or multiple organizations) cannot easily use the GitHub MCP server across all their accounts. Currently, the server only supports a single GitHub token, forcing users to either:

  • Choose one account and lose access to the other
  • Manually reconfigure and restart the server when switching accounts
  • Run multiple server instances (complex and resource-intensive)

This is especially problematic for Enterprise Managed Users (EMU) who cannot contribute to external open source projects from their work account but need access to work repositories during the day.

Describe the solution you'd like

Add multi-account support to the GitHub MCP server with automatic account switching based on repository context. Similar to how Git's includeIf enables automatic user configuration switching by directory, the MCP server should intelligently route requests to the appropriate GitHub account.

Proposed Implementation

Configuration Format

{
  "accounts": [
    {
      "name": "work",
      "token": "${GITHUB_WORK_TOKEN}",
      "matcher": {
        "type": "org",
        "values": ["my-company", "my-company-org"]
      }
    },
    {
      "name": "personal",
      "token": "${GITHUB_PERSONAL_TOKEN}",
      "matcher": {
        "type": "org",
        "values": ["drtootsie", "my-personal-org"]
      },
      "default": true
    }
  ]
}

Routing Logic

1. When a tool is called with an owner parameter, match against account matchers
2. Use the matched account's token for that request
3. Fall back to the default account if no match
4. If no default specified, use the first account

Alternative: Repository-based Routing

For more granular control:
{
  "accounts": [
    {
      "name": "work",
      "token": "${GITHUB_WORK_TOKEN}",
      "matcher": {
        "type": "repo_pattern",
        "patterns": ["my-company/*", "my-company-org/*"]
      }
    }
  ]
}

Describe alternatives you've considered

1. Multiple Server Instances: Run separate MCP servers for each account
  - ❌ Resource intensive
  - ❌ Complex configuration
  - ❌ No automatic switching
2. Manual Token Switching: Stop and restart server with different tokens
  - ❌ Disruptive workflow
  - ❌ Loses active context
  - ❌ Not practical for frequent switching
3. Proxy/Middleware Layer: Build external routing layer
  - ❌ Adds complexity
  - ❌ Not integrated with MCP protocol
  - ❌ Difficult to configure

Additional context

Real-World Use Case

Morning: Working on work repos
  MCP → Detects owner="my-company" → Routes to work token ✅

Lunch break: Want to contribute to OSS
  MCP → Detects owner="drtootsie" → Routes to personal token ✅

Afternoon: Back to work repos
  MCP → Detects owner="my-company" → Routes to work token ✅

Benefits

- ✅ Seamless workflow: No manual configuration changes
- ✅ Context-aware: Automatic based on repository/org
- ✅ EMU-friendly: Use personal account for OSS, work account for enterprise
- ✅ Backward compatible: Single-account config still works
- ✅ Security: Each account's token only used for appropriate repos

Related Issues

- #471, #472: Multi-user HTTP mode (server-side multi-tenancy)
- #1333: GitHub App authentication
- #132: Non-PAT auth methods

This feature is complementary to those - it addresses client-side multi-account scenarios for individual users, while those address server-side multi-user deployments.

Impact

This would significantly improve the experience for:
- 👥 Users with work + personal GitHub accounts
- 🏢 Enterprise users with EMU restrictions
- 🔄 Contributors to multiple organizations
- 🌍 Open source maintainers with day jobs

Would you be willing to contribute this feature?
Yes! I'm prepared to implement this feature and submit a PR.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions