From Zero to AI Auto-Posting on X in Four Steps

You want an AI to post on X for you. Not manually, not half-automated, but a pipeline where a model drafts, you approve, and the platform publishes. This is doable in an afternoon if you already have a developer account. If not, budget a few hours for approval delays.

The path is exactly four steps: developer portal, app and keys, a test post, then handing the loop to Codex. Each step has a trap. This guide walks you past all of them.

Step 1 - Developer Portal: Project and App

Go to developer.x.com and sign in with the account that will own the posts. This is not the same as your normal X login flow. You need to agree to the developer terms, which include rate limits and automation rules. Read those terms once. They change, and the free tier has posting limits that are lower than you expect.

Once inside, create a Project. A Project is a container for one or more Apps. For a solo builder, one Project and one App is enough. Name it something you recognize later, like “content-bot” or “news-poster”.

After the Project, create an App inside it. The App is the actual credential holder. You will see an App name and an App ID. Copy the App ID somewhere safe, but do not put it in a file that syncs to the cloud. A local note file is fine.

Now the access tier. As of the source material, the Free tier allows posting but with a low monthly cap. The Basic tier costs money and raises limits. Check the official pricing page before you commit. Do not assume the free tier is enough for daily posting. If you plan more than a few posts per hour, you need Basic or higher.

The key decision here: choose the tier that matches your expected volume. If you are testing, start Free. If you know you will post daily, go Basic. You can upgrade later, but the approval process for a higher tier can take days.

Step 2 - Permissions and Keys

In the App settings, find the “User authentication settings” section. This is where you set what the app can do. For auto-posting, you need Read and Write. Do not enable Direct Message access unless you specifically need it. Least privilege is the rule: if a key leaks, the attacker gets only what the key allows.

Generate your keys. You will get four values: API Key, API Key Secret, Access Token, and Access Token Secret. Some newer apps use OAuth 2.0 with a Bearer Token instead. Either works for posting. The four-value set is simpler to understand, so use that for a first implementation.

Here is the hard rule: these keys live in environment variables only. Never hardcode them in a script. Never commit them to Git. If you push a repo with a .env file that contains keys, assume the account is stolen. The moment you realize a key leaked, revoke it in the developer portal and regenerate. Do not wait.

On your local machine, set them like this:

export X_API_KEY="your_key"
export X_API_KEY_SECRET="your_secret"
export X_ACCESS_TOKEN="your_token"
export X_ACCESS_TOKEN_SECRET="your_token_secret"

On a server, use the platform’s secret manager. On a local dev machine, a .env file loaded by a tool like direnv is acceptable, but ensure .env is in .gitignore.

Step 3 - First API Post

Before any automation, prove the pipeline works. Use a simple script that posts one tweet. The easiest way is with tweepy, a Python library that wraps the X API.

Install tweepy:

pip install tweepy

Then create a file named test_post.py:

import os
import tweepy

client = tweepy.Client(
    consumer_key=os.environ["X_API_KEY"],
    consumer_secret=os.environ["X_API_KEY_SECRET"],
    access_token=os.environ["X_ACCESS_TOKEN"],
    access_token_secret=os.environ["X_ACCESS_TOKEN_SECRET"]
)

response = client.create_tweet(text="Hello from the API. This is a test post.")
print(response)

Run it:

python test_post.py

If you see a response object with an id field, the post went through. Check your X account. The tweet should be live.

If you get an error, the most common cause is wrong permissions. Go back to App settings and confirm Read and Write are enabled. Then regenerate the Access Token. The token is tied to the permission level at generation time. Changing permissions after token creation invalidates the token.

Another common error is rate limiting. The free tier has a per-day cap. If you hit it, wait 24 hours or upgrade.

Once the test post works, delete the script or keep it as a reference. The point is to confirm the credential path is correct.

Step 4 - Automate Posting with Codex

Now the interesting part. You want Codex, the AI coding agent, to handle the posting loop. Codex can write and run scripts, but it should not have direct access to your keys. Instead, pass the keys via environment variables to the process that Codex runs.

The instruction template for Codex should be explicit. Do not say “post something interesting.” That will produce garbage. Give it a topic, a source scope, posting rules, and a human review step.

Here is a working template:

You are a content scheduler for an X account about AI tools for solo builders.

Topic: practical AI automation tips for indie hackers.
Source scope: only use information from the provided RSS feed or article list. Do not invent facts.
Posting rules: no more than 10 posts per hour. Each post must be under 280 characters. Include one relevant hashtag. Never post the same link twice.
Human review: write the draft, then wait for my approval before posting. Do not auto-post without a "send" command.
Sensitive words: reject any draft containing the words "guaranteed", "risk-free", "millionaire", or "secret".

Save this as posting_instructions.md. Then run Codex with a command like:

codex "Read posting_instructions.md, generate the next post, and wait for my approval."

Codex will read the instructions, generate a draft, and stop. You review the draft, edit if needed, then say “send” or approve. Codex then runs the script that posts via the API.

The critical part is the human review step. For important accounts, start in “draft review” mode. The agent only writes drafts. A human hits send. This prevents an AI from posting something embarrassing or wrong. Once you trust the output, you can relax the rule, but keep a human in the loop for the first week.

Rate limits are non-negotiable. Even if the API allows more, set a cap in the instructions. Ten posts per hour is a safe default. More than that looks like spam, and X’s automation rules are strict. Spam behavior gets your app flagged, and the account can be suspended.

A sensitive-word filter is also a must. AI models do not know what is risky for your brand. Give it a list of banned words or phrases. If a draft contains any, the agent must discard it and generate a new one.

Safety Red Lines

A leaked key means a stolen account. There is no recovery if an attacker uses the key to post spam or reset your password. Treat keys like passwords. Rotate them monthly if you are paranoid.

Least privilege applies to the app permissions. Read and Write is enough. Do not enable Direct Message access. Do not enable account deletion permissions. The less the key can do, the less damage a leak causes.

Follow X automation rules. The platform bans accounts that post repetitive content, use multiple accounts to evade limits, or post at unnatural speeds. The rules are on the developer portal. Read them.

Ban risk is your own responsibility. This guide shows you the technical path, but it does not guarantee your account will stay active. If you push the limits, you pay the price.

Final Notes

The four-step path is short, but each step has a failure mode. The developer portal approval can take time. The permissions must match the token generation. The first post must succeed before automation. And the automation must have a human review gate.

Start with a test account if you have one. Run the pipeline for a week in draft mode. Then, and only then, let the AI post without review.

(Figures and case details in this article are as reported in the source material and have not been independently verified.)

Series: AI Practice