Codex and GitLab: From Code to Production in Three Stages
Codex writes code in the terminal quickly, but that is only half the job. GitLab adds context: requirements from an issue via MCP, collaboration in a merge request, a CI/CD pipeline and human approval. The article walks through three scenarios: a local fix, a fix driven by requirements, and help with code review.
AI-processed from GitLab Blog; edited by Hamidun News
Codex is an AI agent for coding in the terminal. It writes code, runs tests and commits to a branch, all quickly. But writing code is only the first step. After that you need a task, a pull request, CI/CD, code review and a human decision on merge. GitLab helps connect Codex's speed with the context production requires.
Codex locally: from bug to code
The first scenario runs in the terminal. In the Tanuki IoT Platform project, there is a WebSocket bug: filtering metrics by type does not work. You describe the task to Codex, and it analyzes the Rust code, finds the missing `metric` parameter, adds the filtering and writes tests. After you review the result, Codex creates a branch, commits and pushes. GitLab CI checks Rust style and runs the tests. The change is ready to merge.
Here the agent works with the repository and a local AGENTS.md file, which describes what a good implementation looks like.
GitLab MCP: requirements context
The second scenario adds depth. Codex can now pull information from a GitLab issue via MCP (Model Context Protocol). Issue #32 lists the requirements: tests, documentation and updates are needed. Instead of copying everything into the prompt, you simply ask Codex to "help implement issue 32", and it loads the requirements directly from GitLab.
Now the fix accounts not only for the technical solution but also for business requirements. Codex creates a pull request with an automatic "Closes #32":
- Reads requirements from the issue via MCP
- Implements the change with all the details in mind
- Creates an MR that closes the issue on merge
- Links the code to the requirements
- Makes the agent part of the delivery workflow
This is no longer local coding but participation in the delivery process.
An external agent in the merge request
The third scenario is the most interesting. Code review points out problems: documentation and error-case tests are missing. You mention Codex in an MR comment (@ai-codex-agent), and the agent now works in the context of the pull request. It sees the diff, the feedback, the CI results and the approvals. Codex adds documentation, writes the missing tests, commits and runs the checks. It then posts a reply back in the MR.
The merge request becomes the central surface: the code is here, the review is here, the agent helps here, and the human approves here.
What this means
Coding has become fast, but speed without context is an assembly line of patches. When the agent sees requirements (from the issue) and collaboration (from the MR), the result is meaningful work. It joins the speed of code with the context of production: the agent works fast, and the human makes the decisions.
- Nov 1, 2026Local models lose to Opus and Codex: 0.21 on a MacBook versus 1.00 for Codex
- Nov 1, 2026Adobe's EditAgent judge picks a usable edit 81.3% of the time, versus 74.8% for EditScore
- Nov 1, 202616 models tested on 7 search tools: Exa averaged 10.5 out of 14, SearXNG about 3
- Nov 1, 2026Google's StreamVibe video agent beats other models by 10.7% on response timing and quality
Key Questions Answered
What are the key details on Codex locally: from bug to code?
The first scenario runs in the terminal. In the Tanuki IoT Platform project, there is a WebSocket bug: filtering metrics by type does not work. You describe the task to Codex, and it analyzes the Rust code, finds the missing `metric` parameter, adds the filtering and writes tests. After you review the result, Codex creates a branch, commits and pushes. GitLab CI checks Rust style and runs the tests. The change is ready to merge. Here the agent works with the repository and a local AGENTS.md file, which describes what a good implementation looks like.
What are the key details on GitLab MCP: requirements context?
The second scenario adds depth. Codex can now pull information from a GitLab issue via MCP (Model Context Protocol). Issue #32 lists the requirements: tests, documentation and updates are needed. Instead of copying everything into the prompt, you simply ask Codex to "help implement issue 32", and it loads the requirements directly from GitLab. Now the fix accounts not only for the technical solution but also for business requirements. Codex creates a pull request with an automatic "Closes #32": Reads requirements from the issue via MCP Implements the change with all the det
What are the key details on An external agent in the merge request?
The third scenario is the most interesting. Code review points out problems: documentation and error-case tests are missing. You mention Codex in an MR comment (@ai-codex-agent), and the agent now works in the context of the pull request. It sees the diff, the feedback, the CI results and the approvals. Codex adds documentation, writes the missing tests, commits and runs the checks. It then posts a reply back in the MR. The merge request becomes the central surface: the code is here, the review is here, the agent helps here, and the human approves here.
Build & Ship Production AI Agents Without Boilerplate Code
Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.
