Contexts (Multi-Project)
Contexts allow you to manage multiple project configurations in a single config file and switch between them. This is especially useful for AI agents that work across several repositories.
Why contexts?
Without contexts, the architecture follows a 1 server = 1 project model. If you work on multiple projects, you'd need to restart the MCP server or maintain separate config files. Contexts solve this by letting you define multiple project profiles and switch between them.
Defining contexts
Each context is a named group of provider configurations under the [contexts.<name>] section:
A context can include any combination of providers (GitHub, GitLab, ClickUp, Jira).
Switching contexts
CLI
MCP tools
When running as an MCP server, the following tools are available:
AI agents can use these tools to discover available projects and switch between them mid-conversation.
Token resolution
Tokens are resolved in the following order:
- Context-scoped token:
contexts.<name>.<provider>.tokenin keychain - Global provider token:
<provider>.tokenin keychain (shared fallback)
For most setups, a single global token per provider is sufficient.
Active context resolution
When no context is explicitly selected, DevBoy resolves the active context in this order:
- The
active_contextfield in the config (if it points to a valid context) - A context named
default(explicit or legacy) - The first context alphabetically
Backward compatibility
Existing single-project configs continue to work. Top-level provider sections are treated as an implicit default context:
This is equivalent to:
If both exist, the explicit [contexts.default] takes precedence.