Pit Stop One: Installing the Codex CLI
Installing Codex CLI is the shortest leg of the sprint, and it is the leg most people rush. The tool runs on Node.js, so confirm the runtime first, install the package globally, and then verify that the binary actually answers on your command line before you configure anything else.
- Node.js 18 or newer on your PATH, checked with node --version
- npm available, checked with npm --version
- A terminal you really work in, because the CLI inherits its working directory as context
- Git configured with your name, email, and push access to the repository
With those in place, the install is one command: npm install -g @openai/codex. When it finishes, run codex --version. If the shell reports that the command is not found, your global npm prefix sits outside the PATH; print it with npm config get prefix and add the matching bin directory to your PATH before retrying.
Open the CLI inside the repository you intend to change, never in your home directory. Codex reads the files around it, so the launch folder defines the scope of every request. A quick codex --help confirms the install and shows the subcommands you will use for sign-in and model selection.
Wiring the Relay Before the First Prompt
Codex CLI speaks the OpenAI-compatible wire format, which means the only wiring it needs is a base URL and a key. With SwiftRelay, OpenAI-style clients point at https://api.fastapirelay.com/v1, and the /v1 suffix matters, because the same relay serves Claude Code and Gemini CLI with the bare host.
Export two variables in your shell profile or your project environment file: OPENAI_BASE_URL set to https://api.fastapirelay.com/v1, and OPENAI_API_KEY set to the key from your SwiftRelay dashboard. Then launch Codex and take the API key sign-in route instead of the interactive browser flow. Nothing else in the CLI changes, which is exactly the point of an OpenAI-compatible relay.
New accounts receive a small gift credit, so the first real task does not have to wait on a budget conversation, and inviting friends earns 14% of their top-ups as the team grows. Billing is per token, which suits a CLI you launch in short bursts rather than one you keep running all day. If you do not have an account yet, sign up for SwiftRelay and copy the key from the dashboard.
Write the variables down once and reuse them everywhere. The same two lines work in a laptop shell, a container, and a CI job, so your first merged change and your hundredth are configured the same way.
Two Ways to Run Codex CLI Side by Side
Before you settle into a workflow, it helps to line up the two realistic setups and judge them on the things that actually affect daily work: authentication, model reach, billing shape, and portability.
- Authentication. The direct route stores a provider login on the machine and is fine for a solo laptop. The relay route uses one API key in environment variables, which travels cleanly to teammates, containers, and CI without a browser step.
- Model reach. The direct route keeps you inside one provider catalog. The relay route keeps Codex itself while opening the door to other families, so a careful code review run can use GPT-5.6 Sol and a cheaper exploratory run can use DeepSeek V4 Flash without touching your CLI config.
- Billing shape. The relay bills per token on a pay-as-you-go basis, which matches how a CLI is actually used: short, spiky sessions around real tasks. The direct route ties spend to whatever the provider account carries.
- Portability. With SwiftRelay the same credential covers Codex, Claude Code, Gemini CLI, and any OpenAI-compatible SDK, with the bare host for the first two and /v1 for SDK clients. The direct route is one tool deep.
The direct route has one genuine advantage: if your organization already provisions a provider account and enforces it through policy, staying inside that boundary removes a conversation with security. For a solo developer or a small team, that constraint rarely applies.
The relay route wins on everything else, and it keeps a mixed toolchain honest. If you use Codex for implementation and another CLI for review, one API host and one per-token bill are far easier to reason about than two separate arrangements.
First Run: From Prompt to Patch on a Working Branch
Now the green light. Pick a small, self-contained change you would be comfortable merging yourself, because the first run is a calibration lap, not an architecture rewrite.
- Create a branch. git switch -c codex/first-run keeps the experiment isolated and makes the diff easy to throw away.
- State the acceptance criteria. Describe the behavior you want, the files it may touch, and the tests that must stay green.
- Let the CLI run commands. Ask it to run the test suite itself and report failures instead of guessing.
- Inspect the diff. Start with git diff --stat, then read the full diff before you accept anything.
- Commit with intent. Write a message a reviewer can read without opening the branch.
Concrete prompts beat clever ones. Name the module, the expected output, and the edge case you care about, and explicitly ask the CLI to avoid unrelated files. Vague requests produce broad diffs, and broad diffs are what slow a first merge down.
When the patch is small and the tests pass, push the branch and open a pull request. A reviewer who sees one focused change and a clean test run will merge it quickly, and that merge is the real finish line of the lap.
Review Checklist Before the Green Light
Run through this list every time, not just on the first attempt. It is the difference between a patch that ships and a patch that bounces back.
- Scope. Does the diff contain only the change you asked for, with no stray formatting or generated noise?
- Tests. Did the suite run in your environment, and did you add coverage for the new behavior?
- Secrets. Are keys, tokens, and hostnames absent from source, config samples, and commit history?
- Names. Do functions and variables read like the surrounding code rather than like model output?
- Docs. Does any documented behavior or example need a matching update?
- Message. Does the commit explain the why in one line a teammate can scan?
If any answer is no, send the CLI back with a specific correction instead of editing blindly yourself. Iterating through the tool keeps the workflow reproducible.
The Recommendation: Put the First Lap on the Relay
My clear recommendation is to run Codex CLI through SwiftRelay from the start. The setup cost is two environment variables, the billing follows your actual token usage, and the same credential keeps working when you add another CLI or an OpenAI-compatible SDK to the toolchain.
Choose the direct provider route only if your organization mandates a single provider account for compliance reasons. Everyone else gets more flexibility from the relay with no extra moving parts, plus a small gift credit to spend on the first run and 14% of friends' top-ups once the team grows.
Install the CLI, set the base URL and key, branch, prompt, review, and merge. That checklist takes one focused session, and after it the tool is part of how you ship rather than something you still mean to try.