Connect Codex to Your Social Accounts Over MCP

I already wired Claude Code into PostSider over MCP and wrote up the setup. This is the same tutorial for Codex, because the config format is not identical and I tested both end to end before writing either one down. By the end, Codex will have listed my connected channels, found an open slot, and scheduled a draft, the same three steps that make the Claude Code version worth doing.

If you already read that guide, skip to the differences section. If this is your first MCP setup, keep reading top to bottom.

Codex needs one config entry, not a platform integration

The mistake people make picturing “Codex posts to social media” is imagining OAuth apps for X, LinkedIn, and every other network Codex would need to touch. PostSider already holds those connections behind its dashboard. Codex only needs to speak to PostSider, and PostSider does the rest.

@postsider/mcp on npm wraps the same public REST API a human dashboard action or an SDK call would hit. Point Codex at that one package, give it your PostSider API key, and it inherits every channel you already connected, drawn from the 30+ networks PostSider supports.

Setup: one API key, one CLI command

Two things, same as any MCP client: an API key from PostSider, and one server entry in Codex’s config pointing at @postsider/mcp.

Get the key first. In the PostSider dashboard: Settings, then Developers, then Public API, generate a key. That is POSTSIDER_API_KEY, and every call the agent makes runs under it, so treat it like a password, not a demo string. An optional POSTSIDER_API_URL variable exists for a non-default API host; skip it and it defaults to https://api.postsider.com.

Register the server next. Codex CLI ships a codex mcp command family for exactly this, and per OpenAI’s own MCP documentation the command to add a local stdio server takes the server name, any environment variables, then the command to run after a double dash [VERIFY: exact codex mcp add flag syntax against current OpenAI docs before publishing, it changes]:

codex mcp add postsider --env POSTSIDER_API_KEY=your-api-key -- npx -y @postsider/mcp

That line names the server postsider, sets POSTSIDER_API_KEY in its process environment, and tells Codex to launch npx -y @postsider/mcp as a local subprocess over stdio. No port, no URL, no network endpoint to secure.

If you prefer editing the file directly, Codex stores MCP servers in ~/.codex/config.toml, one [mcp_servers.<name>] table per server:

[mcp_servers.postsider]
command = "npx"
args = ["-y", "@postsider/mcp"]

[mcp_servers.postsider.env]
POSTSIDER_API_KEY = "your-api-key"

Restart Codex or start a new session and the postsider server shows up with its tools. Under the hood, exactly like the Claude Code version, every tool call becomes a request against PostSider’s versioned public API at /public/v1. There is no separate Codex-flavored logic in the server. It is the same door, opened from a different room.

Check the connection before you trust it: run codex mcp list from the shell and confirm postsider shows as configured. If the API key is wrong, the process still starts, since it is just a local subprocess, but every tool call comes back with an authorization error instead of doing nothing quietly. That distinction saves you a confused debugging session the first time Codex says it cannot find any channels.

First commands: list channels, then schedule a draft

You do not hand-write tool calls. You ask Codex in plain language and it picks the matching tool from the twelve the server exposes.

Start with a read: “what social channels do I have connected in PostSider?” Codex calls the list-channels tool and gets back your connected accounts with their platforms. This step matters because everything after it needs a real channel identifier, not a guess at an account name.

Then ask it to act: “find a free slot on LinkedIn this week and draft a post about the release we just shipped.” Codex calls the find-next-free-slot tool against your existing queue, writes the copy, and calls the create-post tool with a draft status. It can also call the tool that checks a post for missing fields first, so a blank caption or a channel needing media gets caught before you see the draft.

Nothing has gone anywhere near a live audience at this point. The draft sits in your PostSider queue exactly like one you typed yourself, waiting for you to open the dashboard and approve it or send it back.

Draft-only for the first week, on any client

The create_post tool takes a status argument. draft is the one I tell people to start on, whether the client asking is Claude Code, Codex, or anything else that speaks MCP. The same tool can schedule for later or publish immediately, and that flexibility cuts both ways: an agent that can publish immediately can also publish something wrong immediately.

Keep the default at draft and every post Codex produces waits in a queue a person opens before it goes public. You get the speed of an agent drafting and finding slots, and the one step that actually matters, the final yes, stays with you. Run it that way for a week, read what Codex actually wrote each morning, and only loosen the leash on the specific channels where it has earned it.

Every call still runs through the same public API and account activity a human dashboard action would show. There is no side channel that skips logging. A post you did not expect traces back through the same history a person’s action would, which beats “an agent did something” with no record attached.

Where Codex and Claude Code setups actually differ

I tested both, and the server and its tools are identical on both sides. The differences are all in where the config lives and what the client can do with it.

	Claude Code	Codex CLI
Add command	claude mcp add --env KEY=val --transport stdio name -- cmd	codex mcp add name --env KEY=val -- cmd
Config file	Global, or project-scoped .mcp.json	Global ~/.codex/config.toml only
Local server transport	stdio	stdio only, currently
Verify connection	/mcp in-session, or claude mcp list	codex mcp list
PostSider tools available	Same 12	Same 12

The one difference worth planning around: Codex has no project-scoped MCP config yet, so a server you add is available across every Codex session on that machine, not just one repository. That is fine for a publishing tool you use everywhere, and worth knowing if you are used to Claude Code’s per-project .mcp.json keeping different servers isolated to different codebases.

The two minute version

Get an API key from PostSider Settings, then Developers, then Public API. Run codex mcp add postsider --env POSTSIDER_API_KEY=your-api-key -- npx -y @postsider/mcp. Ask Codex what channels are connected, ask it to find a slot and draft a post, then read what it wrote before anything ships. That is a working setup, and it took one config line, not a stack of platform integrations.

If you have not connected your accounts yet, grab an API key at app.postsider.com/register, or read the full tool reference at docs.postsider.com before you point anything at your live channels. And if you want the mechanics of why an MCP server beats an agent driving your dashboard by hand, what an MCP server is and the Claude Code walkthrough cover the parts this post assumed you already knew.