OpenAI Codex in VS Code: Set Up a Reviewed Coding Workflow

OpenAI Codex CLI is a command-line coding agent. You run it from a terminal alongside your VS Code workspace rather than installing it as a VS Code extension. It reads context from your repository, can execute shell commands in a sandboxed environment, edits files, and runs tests. The workflow is: give it a specific task, let it propose changes, review the diff in VS Code before staging anything, and commit only code you have read. A tool like fenbs keeps the approved requirements and unfinished work outside Codex so they are available when the next session starts, in Codex or in any other connected coding tool.

Installing and authenticating Codex CLI

Codex CLI is an npm package. Install it globally with npm install -g @openai/codex (or pnpm add -g @openai/codex). You need an OpenAI API key with access to the Codex model. Store the key in the OPENAI_API_KEY environment variable; Codex CLI reads it automatically. For details on obtaining and managing your API key, see the Codex API key guide.

Run codex --help in a terminal to confirm the installation. Open your VS Code workspace in one window and a terminal alongside it. You give tasks to Codex CLI in the terminal and review the resulting file changes in VS Code.

Giving Codex useful repository context

Codex CLI reads an AGENTS.md file in the repository root. This file tells it about the project: the stack, the coding conventions, the test command to run, and any files or directories it must not touch. A focused AGENTS.md produces better output than a vague one.

Keep AGENTS.md current. If the project adds a new framework or changes a test runner, update the file. An outdated context file is worse than no context file because Codex will follow the wrong instructions confidently.

Writing a good task description

Give Codex a task description that names the specific change, the files involved, and any constraints. "Add input validation to the signup endpoint in handlers/auth.go; the validation must reject empty email and password fields and return a 400 status" is better than "add validation to the auth handler". A specific task produces a narrower diff that is faster to review.

• Name the specific file or function, not the feature area.
• State the expected behavior and the test you expect to pass.
• List any files or patterns Codex must not change for this task.
• If the task has a known prior attempt, describe what did not work.

Reviewing changes in VS Code before committing

Codex CLI proposes file changes and, in non-sandboxed mode, can apply them directly. Use the VS Code Source Control panel to review every changed file before staging. Confirm that the diff matches what the task description asked for, that no unintended files changed, and that the tests pass. Run git diff in the terminal to see a full diff alongside the VS Code view.

If the diff is larger than the task warranted, investigate before committing. Codex sometimes makes opportunistic changes to adjacent code. Those changes may be improvements, but they should be reviewed on their own merits. How Codex compares to GitHub Copilot for day-to-day use is covered in Codex vs GitHub Copilot. For a comparison with Cursor, see Cursor vs Codex.

Approval modes and when to use each

Codex CLI runs in different approval modes that control how much it can do without asking you. In the default sandboxed mode it proposes changes and waits for your approval before applying them. In auto-edit mode it applies file edits without asking but still asks before running shell commands. In full-auto mode it can both edit files and run commands without interruption.

Start with the default sandboxed mode until you are comfortable reading Codex's output. The review step is not a bottleneck — it is the part where you stay in control of what goes into the repository. As your confidence in Codex's output grows for specific task types, you can use auto-edit for those tasks while keeping sandboxed mode for anything that involves commands or sensitive files. The mode is set per session with a flag, so switching is easy.

Handling sessions and handoffs

Codex CLI runs as a single session in the terminal. When you close it, the session context is gone. If you have unfinished work, save it before closing: what was completed, what was tested, and what the next step is. That record belongs in a persistent store, not in the terminal history.

How to do this with fenbs

1. Create a free account and add a project for the repository you are working on.
2. Record the project requirements and constraints as Decisions and rules. Include the conventions from your AGENTS.md so both the file and the fenbs record stay in sync.
3. Add tasks for each piece of work in progress. Note the current status, the next step, and any known constraints.
4. Connect Codex CLI from Integrations. Ask it to read the project context at the start of each session.
5. Before closing the terminal, ask Codex to save its progress on each task to fenbs. The next session — in Codex or another supported tool — starts from Where we left off.