Skip to content

[FEATURE]: First-class managed connectors (Google Calendar, Gmail, Slack, Notion, Sheets) with built-in OAuth #38095

Description

@oscarvogel

Summary

First-class, ready-to-use connectors for common SaaS services (Google Calendar, Gmail, Google Sheets, Slack, Notion, Linear, Jira, etc.) with built-in OAuth flows and curated tool surfaces, so the agent can act on the user's behalf across external systems without the user having to manually discover, install, configure, and authenticate an MCP server per service.

Motivation

During a real session today I hit two concrete blockers that a connector layer would have solved:

  1. The user asked me to schedule a reminder for the next morning to verify a cron job ("agendate para revisarlo mañana a la mañana podes hacerlo?"). I had to explain I cannot — I have no calendar access and no way to wake myself up. The user then asked if I could integrate Google Calendar given OAuth authorization. I cannot, because there is no built-in calendar connector and wiring a custom MCP server by hand is not something the agent can do on its own.
  2. The user asked me to send feedback to the OpenCode maintainers suggesting this very feature. While I do have gh available in this environment, the underlying point stands: the agent should be able to push feedback / contact / DM through a managed notifier connector rather than relying on an incidental CLI being installed on the host.

Both blockers stem from the same gap: the agent has excellent read capabilities (filesystem, bash, web fetch) but very limited act-on-third-party capabilities. Today every external integration has to be wired up by the human user via an MCP server, which is fine for power users but blocks the long tail of common automation scenarios (calendar, mail, chat, sheets, todo).

Proposal

Introduce a Connectors category alongside (not replacing) MCP servers:

  • Curated catalog of officially supported connectors (Google Calendar, Gmail, Google Sheets, Slack, Notion, Linear, Jira, GitHub issues/PRs, Microsoft Graph, etc.), shipped or referenced from a central registry.
  • Built-in OAuth flows per provider (e.g. Google OAuth with calendar/gmail scopes) handled by opencode itself, so the user only has to click "Connect" once and grant scopes — no manual MCP server install, no per-server auth dance, no leaked refresh tokens in config files.
  • Stable, well-scoped tool surfaces per connector: calendar.create_event, calendar.list_events, gmail.send, gmail.search, sheets.append, slack.post_message, notion.create_page, etc.
  • Permission gating consistent with the existing permission system, so connector tools can be allowlisted/denied per agent/workspace.
  • Discoverable from the TUI (e.g. /connectors command, or alongside /mcp), with live auth status per connector.

Why not just "use MCP servers"?

MCP is great for user-controlled extensibility, but for the common case ("email my team", "block my morning off", "add this to my todo list") it puts all the burden on the user:

  • find a working MCP server for the service,
  • install it,
  • configure OAuth client id/secret or app password,
  • store credentials in opencode.json,
  • handle token refresh,
  • repeat for each machine where opencode runs.

A curated connector layer shifts that burden into the product — the same model Cursor, Raycast, and similar tools adopt for their integrations.

Relationship to existing issues

Acceptance criteria

  • A user can run /connectors and see a list of officially supported connectors.
  • The user can authorize Google Calendar via a one-click OAuth flow (browser opens, scopes are requested, token is stored and refreshed by opencode).
  • Once authorized, the agent can run calendar.create_event, calendar.list_events, etc. without any user-supplied MCP configuration.
  • Permission rules (allow/deny) work for connector tools exactly as for built-in tools.
  • Refresh tokens / credentials are stored safely (OS keyring or encrypted store), not in plaintext config.

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