OpenConnector Takes the Token Away From Your Agent. The OAuth Work Does Not Go Anywhere.
The open-source connector gateway is real, Apache-2.0, and sharing Trendshift's featured slot this week. Its own README tells you which deployment path most teams will end up on, and why.
OpenConnector's README puts three deployment options side by side near the top of the page. Under OOMOL's hosted runtime: "Managed OAuth and hosted runtime, ready to use. No deployment or OAuth app setup." Under Cloudflare: "You manage deployment and OAuth apps." Under self-hosted: "You manage storage and OAuth apps."
Then the Quick Start opens with a warning box that says the quiet part out loud: "This starts a self-hosted runtime. OAuth providers require OAuth client credentials from apps you register with those providers. To let users authorize supported providers without setting up your own OAuth apps, use OOMOL-hosted connectors."
That is an unusually honest front page for a project pitching itself as the self-hostable alternative to Pipedream and Composio, and it frames what this whole class of tool actually does. It converts a security problem you cannot solve with discipline into an administrative problem you can solve with paperwork, and then hands you the paperwork.
What it actually is
OpenConnector is a gateway sitting between your agents and the SaaS products they need to touch. You connect a user's app accounts once at the gateway, and the gateway exposes a catalog to agents over the Connector SDK, the oo CLI, MCP, or plain HTTP with a generated OpenAPI document.
The README advertises 1,000+ providers and 10,000+ prebuilt Actions, naming GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, and Slack. Those prose figures now undersell the project. The badges at the top of the README are live, querying OOMOL's own catalog endpoint on every render, and that endpoint returned 1,453 providers and 14,922 Actions when I checked it today. Any number you quote from this project has a shelf life measured in weeks.
The mechanism is the part worth understanding. Provider secrets stay behind the runtime boundary. The agent asks the gateway what Actions exist, reads request and response schemas plus required scopes, picks a connection by alias, and executes. What comes back, in the README's own words, is "the metadata, safe account labels, and execution results needed for the run." The token never enters the agent's context, which means it never enters a prompt, a log line, a trace, or a model vendor's retention window.
Around that sit runtime controls the README lists explicitly: connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit, and redacted run logs. Action executors ship as open source with lazy-loaded executor source, so you can read what a given Action does before an agent runs it. That property is rarer than it should be. Most connector platforms hand you a tool name and a schema and ask you to trust the implementation.
Why the credential boundary earns the trouble
I have read enough agent postmortems to have a firm opinion here. The most common way agent systems leak credentials is not an exploit. It is an API key in an environment variable that surfaces in a stack trace, a debugging print, a prompt someone pasted into a bug report, or the tool-call arguments of a model whose traces a vendor retains for thirty days.
Every one of those paths closes if the credential is never in the process. That is a real, unglamorous security win, and it is the same architectural argument behind this week's other featured Trendshift repo and behind the operational advice falling out of OpenAI's Hugging Face incident report. Keep the secret at the boundary. Give the agent a handle.
The allow and block policy layer matters as much and gets less attention. Once every provider call routes through one gateway, "this agent may read Gmail but may not send" becomes a policy entry instead of a code review. Without a gateway that distinction lives in whichever tool definitions someone wrote, scattered across services, enforced by nothing.
Put this into practice
Start narrow. Do not connect a thousand providers on day one.
Run docker compose up, which pulls ghcr.io/oomol-lab/open-connector:latest rather than building anything, then open http://localhost:3000 for the console and http://localhost:3000/docs for the generated API reference. Hit the no-auth Action from the quickstart, a POST to /v1/actions/hackernews.get_top_stories with an empty input object. That call proves the runtime and the Action contract work with zero credentials at risk. Node 22 or newer if you skip Docker; building from source needs the longer docker compose -f docker-compose.yml -f docker-compose.build.yml up --build.
Then connect exactly one credentialed provider, and make it GitHub with a personal access token rather than an OAuth app. The README shows the whole thing: a PUT to /api/connections/github with authType: api_key, then a github.get_current_user call. A token you can mint and revoke yourself sidesteps the OAuth registration problem entirely for a first pass, which lets you judge the gateway on its merits before you go negotiate with anyone's app review process.
Now point an agent at it. MCP is exposed at http://localhost:3000/mcp, so a Claude Code or Codex host picks up the Actions without an adapter. Before you let it run anything, open the Action contract in the console and read the executor source and the required scopes for the two or three Actions you actually want. People skip this step. It is the one that tells you whether the abstraction is honest.
Set the allow and block policy before you widen access, not after. Decide which Actions a connection may execute while your list is short enough to hold in your head. Turning on fourteen thousand Actions and filtering later is how you end up with an agent that can delete a Notion database because nobody thought to say no.
Only then decide about OAuth, and decide it with the README's note in front of you. If you self-host and you need Gmail or Slack or Google Analytics under real user consent, you register your own OAuth app with each provider, pass their review, and maintain the client secrets. That work is the actual cost of the pattern. No amount of good software design removes it.
What I would want you to know before adopting it
The self-host row of the Usage Paths table is more capable than the marketing suggests, and worth reading before you assume you need the hosted tier. Self-hosting covers local Docker or Node with SQLite or PostgreSQL state and local or S3-compatible transit files. There is a Kubernetes path with a Helm chart carrying PVC-backed storage, migration hooks, Ingress, autoscaling, and NetworkPolicy toggles. There is a Fly.io path and a Cloudflare path running Workers, D1, R2, and Static Assets. The OOMOL hosted row's stated audience is "teams that want users to authorize accounts immediately," and what it sells is OOMOL-provided OAuth apps plus monthly included Connect credits. The product being sold is identity paperwork, priced as credits.
The star count is a mess, and it is worth naming as a habit rather than a fact about this repo. Trendshift's live stats report 5.4k stars, 481 forks, and 6 contributors. GitHub's own HTML page served me 909 stars and 42 forks the same afternoon, and a search index landed at 4.4k in between. I have watched GitHub's cached pages run many revisions behind on other repos this month, so my read is that the low number is stale, but I cannot prove it from a primary source and I am not going to pretend otherwise. The durable lesson is to stop adopting repositories on the strength of a star figure you read once.
Six contributors is the number that should shape your expectations. A catalog of 1,453 providers and nearly 15,000 Actions is a maintenance surface that six people cannot keep current against upstream API drift. Provider code lives under src/providers/<service> with documented contribution rules, which is the right structure. The honest expectation is that the long tail of that catalog is far less exercised than the two dozen providers people actually use, and that you will be the one to discover which.
The commercial relationship is stated plainly, which I appreciate more than I expected to. OOMOL runs the hosted runtime as a business. The README also introduces Wanta, a desktop agent application in the same ecosystem powered by OpenCode, and Wanta is itself open source, runnable locally against your own OpenAI-compatible model with no account, and forkable. There is an optional hosted tier at wanta.ai with managed models and OAuth connections. That is a defensible structure. It also means the friction in the self-hosted OAuth path is not an accident of engineering priorities, and you should expect it to persist.
The license has a carve-out worth reading before you build a product on it. Apache-2.0 covers the source, scripts, tests, and documentation, and explicitly does not grant rights to third-party provider trademarks, logos, brand assets, or documentation. Inclusion in the catalog is not endorsement by the provider. If you plan to ship a wall of logos, that is a conversation with your own counsel.
And the gateway becomes a dependency in the path of every external action your agents take. One process knows every credential and sees every call. That concentration is the point of the design, and it deserves the operational treatment you would give a secrets manager rather than the treatment you would give a library.
Where this leaves you
The interesting question about OpenConnector is not whether it works. It works, the quickstart is genuinely a few minutes, and the architecture is the one the whole field converged on this month.
The interesting question is whether your organization can own OAuth app registration for the providers your agents need. If it can, self-hosting hands you a credential boundary, inspectable Action contracts, and a policy layer under Apache-2.0, and that is a good trade at any star count. If it cannot, you will take the hosted runtime, and you will have swapped one vendor dependency for another while telling yourself you chose the open-source option.
Both outcomes are defensible. Only one of them is what people think they are choosing when they star the repo.
Read the Quick Start note before you decide which one you are.
Sources: oomol-lab/open-connector README (read live from raw.githubusercontent.com with cache busting on August 28, 2026); OOMOL catalog endpoint connector.oomol.com/v1/catalog; Trendshift repository stats.