TL;DR: OpenCLI turns any website into a command an AI agent can run through your real, logged-in browser session, but that only works if the agent runs on the same machine as the browser. A cloud-side agent (Claude.ai in a tab, a scheduled job, a teammate’s chat) has no shell or filesystem access to your laptop, so it can’t call opencli directly. Closing that gap takes a relay: something that lets a remote agent trigger a command on one specific, authenticated device.
If you already run Claude Code with the opencli-browser skill installed, you’ve felt how well this works. Ask the agent to check your Reddit inbox or draft a post, and it opens your actual Chrome, sees your actual login, and does the thing. No API key, no OAuth screen, no rate limit email from a platform you forgot you’d registered with.
Then you try to do the same thing from somewhere that isn’t your laptop. Claude.ai in a browser tab. A cron job that runs at 9 a.m. whether or not your machine is awake. A coworker who wants the same publishing flow but doesn’t have your dev environment. All three hit the same wall: opencli’s command and the browser session it drives both live on one physical machine, and none of these agents are running there.
Why opencli’s model stops at your laptop’s edge
OpenCLI’s own architecture explains the wall. It connects to your browser through a Browser Bridge extension plus a small local daemon, checked with a built-in opencli doctor health command. That daemon is bound to localhost. It has no public address, no listener anyone outside your machine can reach, by design; that’s what keeps a random script on the internet from driving your browser.
Claude Code sidesteps the problem entirely because it already has a bash tool scoped to your machine. It runs opencli the same way it would run ls or git status, in the same shell, on the same box as the daemon. An agent with no presence on that machine has no path in. It can write you a beautiful draft. It cannot press the button.
The two DIY fixes, and what they cost you
There are exactly two honest ways around this, and neither is opencli’s fault to fix, because it was built to be driven locally.
Tunnel the daemon out. Point ngrok or a similar tool at the local port opencli’s daemon listens on, and now a remote request can reach it. Ngrok’s tunnel itself is TLS-encrypted, but the tunnel only carries traffic; it doesn’t decide who’s allowed to send it. You still have to bolt on your own auth (OAuth, a shared secret, IP allowlisting) in front of a daemon that was never designed to sit behind a public URL, keep the tunnel process alive, and handle reconnects yourself.
Skip the local daemon and call platform APIs from the cloud instead. This is what most “social media MCP server” products do, and it trades one problem for a bigger one: you’re back to needing an API key per platform, and plenty of platforms (most short-video and lifestyle apps, and increasingly Reddit for third-party use) don’t hand one out at all. We’ve covered that trade-off in more depth in how MCP servers for social media publishing actually work.
| DIY tunnel (ngrok + your own auth) | Cloud API relay | PublishPort | |
|---|---|---|---|
| Reaches platforms with no public API | Yes, same as local opencli | No, API-gated only | Yes |
| Who builds the auth layer | You | The vendor | PublishPort |
| Who keeps the tunnel/process alive | You | N/A (vendor’s servers) | PublishPort’s relay |
| Runs from your own trusted session | Yes | No, vendor’s cloud IP | Yes |
Bottom line: a DIY tunnel keeps opencli’s real strength (your own logged-in session, any platform it supports) but hands you the auth and uptime work. A cloud API relay removes that work but gives up the platforms without a public API.
PublishPort’s relay: the missing link, not a replacement for opencli
PublishPort exists for exactly this gap. It wraps a maintained fork of opencli (we call it ppcli, published as publishport-opencli) in a desktop client plus an authenticated relay, so a cloud AI agent gets a route to your machine without you standing up ngrok, writing an auth middleware, or babysitting a tunnel process.
The AI side of this stays deliberately small. It gets two tools: list_capabilities(), which reports which platforms are logged in and ready on your machine, and local_bash(), which runs a command there. When the agent wants to post, it reads that command’s --help output and drives it directly, the same way Claude Code would if it were sitting on your box. You can download the client and see your own machine’s capability list once a platform is connected.
Wiring an existing opencli habit into a cloud agent
If you’re already comfortable with opencli’s commands, the setup is four steps and none of them touch a tunnel:
- Install the PublishPort desktop client and sign in.
- Log into each platform through your real browser inside the client, the same session model opencli itself uses. A connected platform turns green.
- Start the local executor so the relay has a live, authenticated path to your machine.
- Copy the generated MCP endpoint and add it to Claude, or any Model Context Protocol-capable client, as a remote server.
From there, a Claude.ai project, a scheduled agent, or a teammate’s chat can call list_capabilities() against your machine exactly like a local Claude Code session would, minus the ngrok tab you’d otherwise have open all day.
What you still have to own
The endpoint from step 4 is the entire gate. Anyone holding it can run commands on your machine through the relay, so it needs the same care as a password, rotated the moment you suspect it leaked. local_bash is real remote execution, and PublishPort gates it with a denylist for destructive or credential-exposing commands plus an AI review step for anything ambiguous, but that’s a filter, not a guarantee, and it can be loosened in the client if you want fewer checks.
None of this changes platform-level risk either. Posting through your own real session removes the most obvious automation signals, a shared data-center IP and a throwaway browser fingerprint, but a real machine posting at bot speed still reads as a bot. Keep the cadence human and follow each platform’s own rules; nothing here promises immunity from rate limits or bans.
Before you wire it up
- Confirm the platforms you need are supported by the opencli adapters (79+ sites at last count, growing as upstream adds more).
- Decide who’s allowed to hold the MCP endpoint, since that’s the one credential worth protecting.
- Keep posting frequency at a pace a real person would use; the trusted session buys you legitimacy, not a bulk-posting pass.
- If you outgrow a single machine, plan for which device stays the source of truth for each platform’s login.
FAQ
Can opencli run on a remote server instead of my own laptop?
Technically yes, if that server has a way to hold a browser session (a headless setup with saved cookies, or a full desktop environment), but then the login belongs to a server, not a device platforms already trust from your own use. Most opencli users keep it on a real machine specifically because that’s what makes the session look ordinary instead of automated.
Does opencli have a built-in way to reach it from a cloud AI agent?
Not out of the box. Its documented path is installing the browser skill into a local AI coding agent like Claude Code or Cursor, which then drives the daemon over the same machine’s shell. Reaching it from an agent that isn’t on that machine is left to whatever relay or tunnel you add yourself.
What’s the difference between opencli and ppcli?
ppcli is PublishPort’s maintained fork of jackwener’s opencli, published to npm as publishport-opencli. It runs the same underlying adapters and commands; PublishPort’s client and relay are the layer added on top so a cloud AI agent can reach it without you managing the daemon yourself.
Is putting opencli’s daemon behind ngrok safe on its own?
No, not by itself. Ngrok encrypts the tunnel, but it doesn’t authenticate who’s allowed to send commands once traffic reaches your daemon. You’d need to add your own auth (a token check, OAuth, IP restrictions) in front of it, since the daemon wasn’t built to sit behind a public URL.
Can I build my own relay instead of using PublishPort’s?
Yes. It’s a real option if you’re comfortable maintaining a tunnel or reverse proxy, an auth layer, and reconnect handling long-term. PublishPort’s relay exists so you don’t have to own that maintenance yourself, in exchange for using its endpoint as the credential instead of one you built.
For the reasoning behind driving platforms from your own machine instead of a cloud server, see why local-environment publishing beats cloud automation. If something above is out of date, the docs are the source of truth.