Codex CLI MCP Setup for Social Posting: Three Timeouts and One Config File to Get Right

TL;DR: Codex CLI connects to a remote MCP server through a [mcp_servers.<name>] table in ~/.codex/config.toml, using url for a Streamable HTTP server. For posting, raise tool_timeout_sec above its 60-second default, keep approvals on prompt or writes, and store the connection address in the user-level file rather than a project file that might reach git.

After a long Codex session I usually end up with something worth sharing: a migration finished, a bug traced to its root. The summary is already sitting in the terminal. Getting it onto X, LinkedIn or Dev.to is a separate trip to a browser. Codex has no publish button, so closing that gap means giving it an MCP server that can post.

The wiring is short, but a few defaults fit reading code better than they fit publishing. Everything below comes from OpenAI’s Codex MCP documentation, and I mark the places where I’m giving my own preference instead.

What the model gets on the other side

PublishPort exposes two generic tools instead of one plugin per platform. list_capabilities() reports which platforms are logged in on your machine, and local_bash(cmd) runs a command there through the relay, using your own browser sessions. The model reads each command’s --help to learn its arguments, so there is no per-platform adapter to maintain. How that works in general is covered in how an MCP server for content publishing works.

On your side: install the PublishPort desktop client, log in to the accounts you want to post from, and copy the connection address from the AI integration page. Treat the address as a credential, because it can run commands on your computer.

Add the server

Per the docs, Codex supports two kinds of servers: STDIO (a local process) and Streamable HTTP (an address). A remote relay is the second kind, so the table needs url, not command.

Edit ~/.codex/config.toml:

[mcp_servers.publishport]
url = "<your connection address>"
tool_timeout_sec = 180
default_tools_approval_mode = "prompt"

The CLI also has codex mcp add, and the docs show it with a --url flag for HTTP servers. The only worked example in the docs is a STDIO one, so check codex mcp add --help on your version. Editing the file is the route I trust more. Afterwards, codex mcp list shows configured servers, and typing /mcp inside the TUI shows which are active.

Two details that cost people time:

• The table name is mcp_servers, with an underscore. A third-party troubleshooting guide, codex.danielvaughan.com, reports that a wrong table name gets the block silently ignored. I haven’t reproduced that, but the underscore is cheap to check.
• The ChatGPT desktop app, the CLI and the IDE extension share this configuration, per the docs. Set it up once and the other surfaces pick it up.

The three numbers worth changing

On the middle row, 180 seconds is my own choice, not an official recommendation. The point of the longer timeout is avoiding ambiguity: if Codex reports a timeout, you can’t tell whether the post went out. If it ever does time out, check the platform before you retry, or you may double-post.

Approvals: don’t hand over auto-pilot

Codex lets you set default_tools_approval_mode per server, with the values auto, prompt, writes and approve. The docs describe writes as prompting for tools that aren’t marked read-only. Publishing has side effects and is hard to retract, so I use prompt and read the text before it goes out. Per-tool overrides go under tools.<tool>.approval_mode, so you could allow list_capabilities without a prompt and keep everything else gated.

For a narrower surface still, enabled_tools is an allow list and disabled_tools a deny list applied after it:

[mcp_servers.publishport]
url = "<your connection address>"
enabled_tools = ["list_capabilities"]

Use the exact tool names /mcp shows, then widen the list once a dry run looks right.

Keep the address out of git

The docs allow a project-scoped .codex/config.toml, read only for trusted projects. That’s convenient for a team’s shared servers and a bad place for a credential. If the address sits in a file inside a repo and someone runs git add ., you’ve committed a key to your machine. Put it in ~/.codex/config.toml. If you must keep it in a project, gitignore that file. If it ever leaked, regenerate the address in the client so the old one stops working.

If you would rather not paste the address into a file at all, the docs offer bearer_token_env_var, which names an environment variable holding a token sent in the Authorization header. Whether that fits depends on how your server authenticates, so check the PublishPort docs for the supported method.

Example: a session summary to two platforms

With the server connected, I tell Codex: “Turn this session’s summary into a short post and publish it to Dev.to and LinkedIn.” It calls list_capabilities() to confirm both are online, reads each publish command’s --help, drafts, and asks for approval before each call. Platform quirks differ, which is why I keep the per-platform notes in automating Dev.to posts and scheduling LinkedIn posts. You get a receipt per platform in the terminal.

If you have never let an agent publish for you, rehearse with a throwaway post first.

Limits

• The desktop client must be running and logged in when Codex posts.
• Real sessions on your own machine don’t exempt you from platform limits. Posting near-identical text to many places in a burst can still be throttled or flagged as spam.
• Config options change between Codex releases. Treat the official docs as the source of truth over this article.
• You are responsible for content quality and each platform’s rules.

Checklist

• [mcp_servers.publishport] with url, in ~/.codex/config.toml
• codex mcp list shows the server and /mcp lists its tools
• tool_timeout_sec raised above 60
• Approval mode prompt or writes, not auto
• Connection address stored like a password, regenerated if exposed

FAQ

Why doesn’t Codex see the server?

Check the table name is mcp_servers and not mcp-servers, then confirm you edited the file Codex actually reads. Project-level .codex/config.toml only applies to trusted projects. Then check the desktop client is running and the address is complete.

Do I use url or command?

command starts a local STDIO process. A remote relay address is a Streamable HTTP server, so use url. This is different from Gemini CLI, where the field is httpUrl. The walkthrough is in Gemini CLI MCP setup for auto-posting.

Can Codex post without asking me each time?

Yes, with the auto or approve modes, but I wouldn’t for publishing. One confirmation costs seconds, and a wrong public post costs more.

Is this the same address other clients use?

Yes. Same address, different key names per client. Only the config format and the entry point change.

Does this work from ChatGPT on the web?

Per the docs, ChatGPT web doesn’t read local Codex configuration files and uses plugins instead. For the web side, see how ChatGPT’s MCP connectors handle social posting.

Ready to try it? See PublishPort pricing and connect your first platform.