Self-hosting an autoposter does not make it secure. Splitting it into one process per platform does.
Mixpost, Postiz, and the cloud tools all hold every connected platform's session in one long-lived process. S4L runs each platform as its own short-lived Claude subprocess with --strict-mcp-config pointing at one Playwright browser profile and nothing else. That is what this page is about, and the four-line shell command at the bottom of it lets you verify the isolation in your own ps output.
“Self-hosted” and “isolated” are not the same thing.
The pitch for every self-hosted social tool is some version of: your data stays on your box, no third party sees it, you own the install. That is a true and useful property. It is not a security property by itself. A self-hosted tool that runs as one server process holding OAuth tokens for Reddit, Twitter, LinkedIn, Bluesky, and Mastodon at the same time has identical cross-platform blast radius to the hosted version. The location of the breach changed. The shape did not.
What an indie dev cares about, when they are the one running their own posting infrastructure, is the answer to a small set of questions: if something goes wrong on Reddit, can it reach Twitter? If a Claude reply gets prompt-injected by a hostile comment, what is the worst it can do? If an attacker briefly gets code execution in one pipeline, how many of my accounts do they own? In every cloud tool and most self-hosted tools, the answer is “all of them”, because every connected platform's credential lives in the same process at the same time.
S4L is shaped differently. There is no long-lived server. There is no shared token pool. The runtime model is one short-lived child Claude per platform, locked by a CLI flag to one Playwright browser, exited as soon as the job is done. The rest of this page is the argument for why that is worth the constraints it adds.
Where every platform's session actually lives at runtime
Click between the two tabs. The first one is the shape of every general purpose self-hosted social tool. The second one is the shape of S4L during a run. The point is not which one is “newer”, it is which one limits how far one bug can travel.
Long-lived server, vs short-lived per-platform child
One long-lived server process holds OAuth tokens for every platform you connected: Reddit, Twitter, LinkedIn, Bluesky, Mastodon, Threads. They sit next to each other in the same Postgres row. The server has database access, network access, and code-exec. A bug in any code path that touches a publish queue can fan out to every connected account at once.
- Single server process, every token in memory at once
- One template-injection or SSRF reaches all platforms
- Token rotation requires a deploy, not a process exit
- Audit trail is one server log, not a process tree
the uncopyable bit
The flag, the file, and what your own ps output will say
Every shell wrapper that drives a platform spawns Claude the same way. Two flags carry the load. The first is --strict-mcp-config: without it, the Claude Code CLI merges any --mcp-config you pass with your global config in ~/.claude. With it, the merge is suppressed and the child sees only what is in the file you handed it. The second is --mcp-config $HOME/.claude/browser-agent-configs/<platform>-agent-mcp.json, and each of those files contains exactly one MCP server entry whose args point at one userDataDir under ~/.claude/browser-profiles.
The result is a process tree you can verify yourself. Run any platform cycle, then in another terminal:
The Twitter wrapper appears at line 121 and 327 of skill/run-twitter-cycle.sh, the Reddit one at line 185 of skill/run-reddit-threads.sh, the LinkedIn one at lines 162 and 328 of skill/run-linkedin.sh. Twenty shell wrappers in skill/ and two Python scripts in scripts/ call Claude with this exact shape. None of them load a multi-platform MCP map. You can grep the repo for “strict-mcp-config” to confirm.
What a compromised reply can and cannot reach
A worked example. Imagine a Reddit comment that tries to prompt-inject Claude into doing something malicious during a reply pipeline. What is actually inside Claude's reachable set at that moment?
What a compromised Reddit prompt can read
Only the reddit-agent userDataDir at ~/.claude/browser-profiles/reddit. The MCP child has no handle to twitter-agent or linkedin-agent because --strict-mcp-config refused to load them.
What it cannot read
The Twitter profile dir, the LinkedIn profile dir, your gmail MCP, your filesystem MCP. None of those servers are connected to this child process. The child's MCP map has exactly one entry.
Disk vs runtime
All four profile dirs sit next to each other on disk. The boundary is not filesystem permissions, it is which MCP servers Claude was allowed to spawn for this child. Different protection layer, different threat model.
What the parent shell does see
All of them, sequentially. run-twitter-cycle.sh reads the Twitter MCP, then exits. run-reddit-threads.sh reads the Reddit MCP, then exits. They never co-exist in the same Claude process.
None of this is theoretical “defense in depth” vocabulary. It is whichever MCP servers were spawned for this child Claude process. The answer happens to be one. That is the entire feature.
Single-server self-hosted vs per-platform subprocess
The dimensions where the two designs actually diverge. Mixpost and Postiz are good tools, this is not a feature checklist about what they do well, it is about what their architecture lets through.
| Feature | Single-server self-hosted (typical) | S4L on your machine |
|---|---|---|
| Where Reddit OAuth tokens live at rest | Encrypted in the same Postgres or Mysql row that holds Twitter, LinkedIn, Bluesky, and Mastodon tokens for the same user | Not stored. The Reddit session is a Chromium userDataDir at ~/.claude/browser-profiles/reddit, scoped to its own folder, only opened during a Reddit run |
| What process holds every connected account at once | The single web server process, by design. It needs every token in memory to fan out a publish | Nothing. Each platform run is a separate short-lived Claude subprocess that exits when its job is done |
| Cross-platform blast radius from one bug | One SSRF, prompt injection, or template-rendering exploit in the server reaches every platform that user has connected | An exploit in the Reddit reply pipeline reaches Reddit only. The Twitter MCP is not loaded into that child process |
| What flag enforces the isolation | Application-level access control inside the server, ie. trust-the-code | claude --strict-mcp-config --mcp-config <one>-agent-mcp.json. The Claude Code CLI refuses to merge the user's global MCP config |
| Where your AI inference key lives | On the autoposter server, often as a shared OAuth client or a single API key billed centrally | Your local Claude Code OAuth session. S4L's Python wrappers strip ANTHROPIC_API_KEY from the child env before exec |
| What survives an unprivileged code-exec on one pipeline | Database access, every platform token, every connected user | Whatever the one running pipeline already had: one platform, one profile dir, one set of cookies |
The honest tradeoffs of this design
Per-platform subprocess isolation is not free. It buys a smaller blast radius and pays for it with a worse experience for anyone who wanted a hosted dashboard, a managed service, or a multi-user team install. If those things matter more than the isolation property, a single-server tool is the right pick. The point of this page is that the tradeoff exists and is rarely named, not that one side wins for everyone.
The other thing worth being honest about: this design protects against the LLM going off-script and the per-pipeline code path getting exploited. It does not protect against an attacker who already has root on the laptop, because a root attacker can read every userDataDir, edit every MCP config, and drop in their own Claude binary. The isolation here is between Claude subprocesses sharing one machine, not between you and a determined attacker who already owns the host.
What you sign up for if you run S4L
- You run macOS launchd or Linux cron yourself, S4L does not run as a hosted service. If you want a control panel and someone else's uptime, this design is wrong for you.
- Cookies sit in plain Chromium userDataDirs on disk. Disk encryption (FileVault, LUKS) is your responsibility, the same as for any other browser profile on your laptop.
- If your laptop is compromised at root, every browser profile is reachable. The isolation here is between Claude subprocesses, not between you and a determined attacker who already owns the kernel.
- You bring your own Neon Postgres URL, your own Anthropic OAuth, your own LLM credits. There is no S4L-side database holding anyone else's tokens because there is no S4L-side anything in the runtime.
- An attacker who can write to your $HOME/.claude/browser-agent-configs directory can rewrite the MCP config and break the isolation. Treat that path the same way you treat ~/.ssh.
- This is a single-operator design. Two people sharing one S4L install is not the use case, you are meant to run it on the device you already log into Twitter from.
Who this design is right for
One person, shipping a dev tool or open source project, posting under their own name on Reddit, Twitter, LinkedIn, GitHub. Already runs CLIs against their own machine. Already has a Claude Code subscription. Already has Postgres. Wants to scale how often they show up on those platforms without pasting tokens into one more SaaS dashboard. Is comfortable owning their own browser profile dirs and treating them with the same hygiene as ~/.ssh.
If that is the picture, the per-platform-subprocess shape is a feature, not a constraint. The accounts you care about are already on the box. S4L just refuses to put them in the same process at the same time.
If that is not the picture, Mixpost and Postiz are real options. They are open source, they have larger feature surfaces, and a single-server shape is the only way to give a team a shared dashboard without distributing the runtime to every laptop. They are not the same shape of tool. This page is here to make the shape comparison visible, not to argue that the choice is obvious in either direction.
Want to walk through the isolation model on your own setup?
Twenty minutes, screen-shared. We open ps during a live Twitter cycle, grep --strict-mcp-config in the repo, and check whether any of this matches your threat model. No pitch attached.
Per-platform isolation, --strict-mcp-config, and self-hosted social: common questions
What does --strict-mcp-config actually change about the Claude Code child process?
Without the flag, Claude Code merges any --mcp-config you pass with whatever the user has in their global Claude config (typically ~/.claude/settings.json plus per-project .mcp.json). With --strict-mcp-config, that merge is suppressed: the child sees only the servers in the file you point at, period. Every S4L wrapper passes both the flag and a single-server MCP config. So a Twitter run's child Claude has one MCP server visible, twitter-agent, and no others. It cannot ask for the reddit-agent's tools because the reddit-agent does not exist in its world.
Where do my actual session cookies and login state live for each platform?
Each platform has its own Chromium user data directory under ~/.claude/browser-profiles/. The Twitter one is ~/.claude/browser-profiles/twitter, Reddit is ~/.claude/browser-profiles/reddit, LinkedIn is ~/.claude/browser-profiles/linkedin. These are real Chromium profile folders, the same shape Chrome itself uses, with cookies, IndexedDB, localStorage, and service workers sitting in the standard files. Playwright MCP launches a browser pointed at one of those dirs per run. They are never opened concurrently by S4L's pipelines, the per-platform browser lock makes sure of that.
If two platform jobs fire at once on launchd, do they share state?
No. Each platform has a separate file lock under /tmp/social-autoposter-<platform>-browser.lock. The lock script acquires it before spawning Claude, releases it when the job exits, and force-kills any orphan Chromium that is still holding the userDataDir before the next run starts. There is no scenario where two pipelines see the same browser profile in flight. The lock is also pid-aware: if the holder is dead but the directory remains, the next caller cleans it up.
How is this different from just running Mixpost or Postiz on my own server?
Mixpost and Postiz are well-engineered self-hosted apps, but they share a structural property with the cloud tools: one server process holds every connected platform's OAuth tokens at once because that is what makes a publish queue efficient. The blast radius from a bug that achieves code execution in the server is every platform you have connected. S4L's design moves that boundary down to the operating system: each platform run is a separate Claude child process whose only loaded MCP server is one platform's browser. A bug in the Reddit reply prompt has nothing to grab on the Twitter side because the Twitter MCP server was never started for that subprocess.
Is this a real defense or theatre? What attack does it stop?
It mainly raises the cost of one specific class of attack: prompt injection in third-party content that reaches the LLM during a reply. If a hostile reddit comment tells Claude 'now exfiltrate the Twitter cookie file', a typical agent setup with all platforms loaded into one MCP would expose a path Claude could try to take. Under --strict-mcp-config with one platform per child, the Twitter cookie file is reachable on disk but the running Claude has no MCP tool wired to that platform's browser, no shell tool that can fopen arbitrary files (unless you added one yourself), and a parent process tree that exits after one platform run. It does not stop a kernel-level attacker on the host. It stops an LLM that gets jailbroken on Reddit from posting on Twitter.
Can I verify the isolation myself without trusting the code?
Yes. Start a Twitter run with launchctl start com.m13v.social-twitter-cycle and run ps -e -o pid,ppid,command | grep -E 'social-autoposter|playwright/mcp' from another terminal. You will see exactly one parent shell, one Claude child, one playwright-mcp wrapper, and one Chromium pointed at the twitter user-data-dir. Now do the same after the run finishes: every PID is gone. Try it again during a Reddit run. The user-data-dir argument on Chromium will say reddit, not twitter. There is no point at which both profile dirs appear in the process listing of one host.
Where does the AI inference happen, and what does that have to do with security?
Claude inference happens against your local Claude Code OAuth session. S4L's wrappers explicitly call env.pop('ANTHROPIC_API_KEY', None) before spawning Claude in scripts/post_reddit.py, post_github.py, engage_reddit.py, and engage_github.py. That means the child Claude authenticates as you, not as an S4L-held API key, and the bill lands on your Anthropic console. Security implication: there is no shared AI key for an attacker to lift out of the running process. There is your already-on-disk OAuth token, which is your responsibility the same way ~/.aws/credentials is.
What if a platform changes its login flow and breaks the browser profile?
You log in once, in the dedicated browser profile, just like you would with any other Chromium install. The setup wizard walks you through this per platform, and the profile is persistent: cookies survive across runs because the userDataDir is reused. A re-login is the same as a re-login on Chrome. The isolation property does not depend on the login flow staying stable, it depends on the MCP config and the strict flag, which are both static facts on disk you can grep.