Codex AI and GitHub: Set Up Repository Access, Review Changes, and Continue Work

Codex is OpenAI's coding agent. It reads your GitHub repository, runs tasks in a sandboxed environment, and can open pull requests with the results. Tools like fenbs keep the scope, decisions, and task progress that Codex depends on — outside any one coding session — so the work continues whether you switch tools, share the repo, or pick up again tomorrow.

The most common problems in a Codex-GitHub workflow are unclear scope and lost context between sessions. Codex is capable of working through a large repo, but it does its best work when it starts with a clear task description and a bounded set of files to touch.

How Codex reads a GitHub repository

Codex connects to GitHub through the GitHub app that OpenAI provides. Once installed, it can clone a repository into its sandboxed environment, read files, run tests, and push a branch. It does not have standing access to every repo; you grant access per organization or per repository when you install the integration.

Codex reads your AGENTS.md file if one is present at the repo root. This file tells the agent how the project is structured, which commands to run, and which areas to avoid. Writing a clear AGENTS.md is one of the highest-return steps in setting up the workflow. See agentic GitHub workflows for patterns that work well across coding agents.

Setting up repository access

1. Install the Codex GitHub app from your OpenAI settings. Grant access to the specific repositories you want it to work on rather than all repositories in the organization.
2. Write an AGENTS.md file at the repo root. Include: the project's purpose, the directory layout, the commands to install dependencies and run tests, and any areas the agent must not modify without a person's review.
3. Create a GitHub Actions workflow that runs tests on every pull request. Codex can read the test results and revise its work before asking for review.
4. Set up branch protection rules on your main branch so Codex can only merge through a reviewed pull request, never by direct push.

Writing tasks that Codex can complete

A Codex task works best when it has one clear goal, a list of files it is likely to touch, and a definition of done. Broad instructions like "improve the codebase" produce unpredictable results. Specific instructions like "add input validation to the email field in src/forms/contact.ts and update the test in tests/forms/contact.test.ts" give Codex a clear target.

Write the task description as if you were explaining it to a developer who is new to the project. Include the relevant background, any constraints, and the expected outcome. A task that is too large to describe clearly is a task that should be split.

Reviewing pull requests from Codex

Review every Codex pull request before merging, even when the tests pass. Codex may produce code that is functionally correct but misses a project convention, introduces an unnecessary dependency, or solves a slightly different problem than the one described. The AI agents for PR review guide covers structured review approaches that work for AI-generated code.

When you request changes, be specific. A comment like "this approach will break the existing cache invalidation logic" gives Codex something to act on. A comment like "this doesn't look right" does not. Treat the pull request review as a conversation with a capable but context-limited collaborator.

fenbs keeps the decisions made during code review as Decisions and rules. If you decide that a certain pattern is not allowed in the codebase, recording it once means every future session — with Codex or any other tool — starts from that rule.

Keeping context across sessions

Codex starts each task in a fresh environment. It reads the repo, reads your AGENTS.md, and reads the task description you give it. It does not automatically know what was decided in yesterday's session, which approach was tried and rejected, or which part of the feature is still incomplete.

Before you end a session, record the current state: what Codex completed, what the tests showed, what was deferred, and what the next task should be. That record is what makes the next session productive without a long recap. Compare how Codex and GitHub Copilot handle multi-session context differently.

How to manage Codex GitHub work with fenbs

1. Create a free account and add a project for the repository you are working on.
2. Add each coding task as a Feature or Enhancement. Put the target files, acceptance criteria, and any constraints in the plan field.
3. Write the standing coding rules — patterns to avoid, review requirements, file areas that need a person's sign-off — as Decisions and rules.
4. Connect your AI assistant over MCP from Integrations and ask it to read the project context before writing the Codex task description.
5. After each session, save progress in fenbs: what Codex completed, what the test run showed, what is deferred, and the next task description.

For a comparison with another agentic coding tool, see Devin vs GitHub Copilot. For an overview of what an AI brain means for a coding project, see what is an AI brain.