Loudcode
Back to blog

How to post to X from Codex (MCP setup guide)

By Naod Tadele · · 5 min read

Loudcode guidePost to Xfrom Codex

Codex does real work in your repo: it reads the code, runs the tests, and explains why it changed what it changed. By the end of a session it holds a better summary of your day than you do. Then you close the terminal, and that summary is gone.

An MCP server lets Codex hand that context to an X tool before the session ends. This guide shows how to connect Codex to Loudcode with three lines in config.toml and one environment variable, what to ask for, and how to keep every post sounding like you.

What you'll be able to do

  • Say "post about what we just shipped" and get a draft in your voice.
  • Say "make it a thread" when the work was bigger than one post.
  • Say "queue it for tomorrow morning" to schedule it on X.
  • Ask "how did my last few posts do?" and see views, likes and replies.

Codex never posts on its own. It saves drafts, and it queues one only when you ask.

Setup

1. Create a key. In Loudcode, open Account settings, find "Use Loudcode in your AI tools (MCP)" and click Create API key. Pick Codex, and Loudcode shows both snippets below with your key filled in. The key is shown once, so copy it now.

2. Add the server to config.toml. Open `~/.codex/config.toml` (create it if it doesn't exist) and add:

[mcp_servers.loudcode]
url = "https://loudcode.dev/mcp"
bearer_token_env_var = "LOUDCODE_API_KEY"

The Codex CLI and the Codex IDE extension read the same file, so this one block covers both.

3. Put the key in your shell. Add this line to your shell profile, like `~/.zshrc` or `~/.bashrc`, with your key in place of YOUR_KEY:

export LOUDCODE_API_KEY="YOUR_KEY"

Then open a new terminal so the variable is loaded.

4. Check it. Run `codex mcp list` in your terminal, or type `/mcp` inside Codex. You should see loudcode in the list.

Prompts to use at the end of a session

  1. "Post about what we just shipped." The everyday one. Codex summarizes the session and Loudcode turns it into a draft.
  2. "Post about the bug we fixed today and what caused it." Debugging stories get replies, because other developers have hit the same wall.
  3. "Turn this week's work into a thread." For launches and big weeks.
  4. "I only cleaned up tests today. What could I post?" Loudcode suggests ideas from your product, numbers and repo.
  5. "Do my weekly Loudcode check-in." Codex answers the check-in questions from what it knows, and Loudcode plans a week of posts.

Here's the kind of draft a session like that can produce, for a fictional on-call tool called Nightshift:

Example post
Fixed a quiet bug in Nightshift today. Incident summaries were sorting alerts by arrival time, not by when they fired. On a slow network that put the root cause at the bottom. Now the first alert is always first. 3 lines of code, 2 hours of finding them.

Give Codex good material

A draft can only be as specific as the summary Codex sends. A few habits help:

  • Say who it's for. "On-call engineers now see the first alert first" beats "fixed sorting".
  • Include the why. If Codex proposed two approaches and you picked one, say "mention why we chose this".
  • Keep the struggle. "Say it took two hours to find" turns a fix into a story.
  • Ask for one post. You can ask for alternatives after you've read the first.

Make it a habit with AGENTS.md

Codex reads an AGENTS.md file for project instructions. Add one line so you don't have to remember:

When we finish a user-facing change, ask if I want a Loudcode draft about it.

The reminder now shows up while the details are fresh, and you can still say no.

Keep it sounding like you

  • Set your voice once. In Loudcode's Voice & tone, pick a tone, list phrases you never use, and paste a few of your past posts.
  • Describe your product. Loudcode adds that context to every draft, so a stranger on X understands what you built.
  • Edit before it goes out. Drafts wait in your Loudcode queue. Rewrite them, schedule them, or skip them.

Troubleshooting

  • loudcode isn't listed. Check that the block is in `~/.codex/config.toml` and that the header reads `[mcp_servers.loudcode]` exactly.
  • It's listed but calls fail. The variable probably isn't set in the shell Codex started from. Run `echo $LOUDCODE_API_KEY` in that terminal. If it's empty, open a new terminal or reload your profile.
  • Still failing with the variable set. The key may be revoked or mistyped. Create a new one and replace it.
  • Drafts stop arriving. Drafts from Codex count toward your plan like any other. The free plan includes 10 drafts a month.

How Loudcode fits in

Codex brings the context of the session. Loudcode brings the rest: your voice, your product description, your posting times, and a queue where you approve every post before it reaches X. It also reads your GitHub commits, pull requests and releases, so quiet weeks still have something to post about.

Using more than one tool? The setup docs cover Claude Code, Cursor, Windsurf, VS Code and Cline too.

You ship the code. We write the posts.

Your commits, revenue, traffic and a 30-second weekly check-in become build-in-public posts for X, in your voice. You approve every post.

Start your free trialTry the live demo

Keep reading

All posts
Loudcode guideBuild in publicmistakesBuild in public mistakes that cost founders followers (and what to do instead)Building in public works until it doesn't. These are the habits that quietly make people unfollow, and what to do instead.Loudcode guideX threadsdevelopers readHow to write X threads developers actually read (structure and examples)Most developer threads lose people after the first post. Here's how to write one they finish.Loudcode guideX MCP serverscomparedTwitter/X MCP servers compared: what each one can doSome X MCP servers give your AI the whole X API. Some give it two tools. One writes drafts and stops. Here's the difference.