Choosing where a task runs
Codex is available as a command-line tool, an IDE extension, a desktop app, cloud tasks started from ChatGPT, and a GitHub integration. The useful decision is by task, not by preference. Work that needs your local environment, or that you want to steer step by step, suits the local surfaces. A well-specified change that can be built and tested from a clean checkout suits a cloud task. We write this down as a short guide so the team does not decide it afresh each time.
AGENTS.md as the shared instruction file
Codex builds its instructions from AGENTS.md files: a global one in your Codex home folder, then files from the repository root down to the directory you are working in, concatenated in that order. An AGENTS.override.md in a directory takes precedence there, fallback file names can be configured, and a combined size cap applies (32 KiB by default), so the instructions have to be economical. A scaffold command creates a first draft; we treat it as a starting point.
Because AGENTS.md is a plain convention, it can be the one shared source for a team that also uses Claude Code, whose CLAUDE.md can import it. Like any instruction file, it is guidance. What must hold is enforced elsewhere.
Sandbox and approvals: two separate dials
Codex separates what the agent is technically able to do from when it must ask. The sandbox mode sets the ability: read-only, workspace-write (the default in version-controlled folders) or full access. The approval policy sets when a person is asked: on request by default, no prompts at all, or a granular setting. They combine, so a workspace-write sandbox with approval on request is a very different posture from full access with no approvals, and we choose per task type.
- Network access is off by default and can be opened selectively, including through allow and deny rules for domains
- Inside the workspace, the .git, .codex and .agents folders are protected as read-only
- Web search is served from a cache by default
- We document which combination is used for which kind of task and who may loosen it
Command rules and project config trust
Codex reads command rules from .rules files, where each prefix rule is marked allow, prompt or forbidden, and the most restrictive match wins. A check command lets us test a rule against a sample command before relying on it. Configuration lives in a user-level config.toml and can also live in the repository; the project layer is applied only for projects you have marked as trusted, so trust is a decision we make explicitly rather than by default. Hooks can also block an action at set points. A rule matches a command shape and can miss an unusual way of doing the same thing, which is why rules are one layer among several.
Designing cloud tasks
A cloud task runs in a container with your repository checked out. A setup script runs first, with internet access, to install dependencies. The agent phase then runs with internet off by default. Secrets configured for the environment are available during setup and removed before the agent phase, and the result comes back as a diff and then a pull request.
This shapes what we build: a setup script that produces a working, testable environment, tasks phrased so they can be verified without outside services, and a decision about what the agent must not need at all. We do not assume the same secret-handling mechanism exists in other tools.
Isolation and worktrees
For local parallel work, Codex can manage worktrees, which are checked out in a detached state so that tasks do not collide. A worktree include file lists ignored files to copy into them, and that convenience can copy secret files such as local environment files, so we review it line by line. We agree how branches are created from detached work and how finished worktrees are cleaned up.
Review and CI
Codex can review pull requests when invoked with a comment, or automatically through the GitHub connector, and it can run non-interactively from scripts, with a read-only sandbox by default, and through an official GitHub Action. We decide where, if anywhere, this belongs in your pipeline and keep the job's permissions narrow. An automated review is an extra reader, not a replacement for your reviewers.
Organisation requirements
For larger teams, administrators can enforce requirements users cannot override, delivered through a requirements file, cloud-managed configuration or device management. Which of these applies depends on how your organisation uses Codex; we check it at assessment rather than assume it.
Onboarding and handover
The team gets a written guide to which tasks to delegate, how to phrase them, what to check in the returned diff, and when to keep a task local. A named owner on your side maintains AGENTS.md, rules and the cloud environment.
How this differs from neighbouring pages
AI-Assisted Development Environment is the vendor-neutral workflow, and Claude Code Setup covers the equivalent for that tool. ChatGPT Implementation for Business is for non-developer staff using ChatGPT in a workspace, not for developers delegating repository tasks.
What this does not promise
We do not promise productivity figures, autonomous engineering or the removal of code review. We do not claim compatibility with every repository, and we make no statements about plans, pricing, data retention or compliance of the tool. Scope is set after we have looked at the repository; timeline depends on repository complexity and existing CI/CD. Project delivery is in English.
How it works
- 1
Repository and workflow assessment
We look at your repository, branching, build, test and release process and the AI tools already in use — read-only, before anything is changed.
- 2
Risks and useful tasks
Where an agent could do harm in this repository, and which tasks are worth delegating to one. You get this in writing, in plain language.
- 3
Permissions, isolation and approval points
What agents may do alone, what needs a person's approval, how parallel tasks are kept apart and where a human must review.
- 4
Project instructions and tool boundaries
Shared instructions for the repository plus the permissions, sandbox and hooks that enforce the important rules, configured inside your own accounts.
- 5
Test, build, lint and CI gates
The checks that must pass before merge or deploy, connected to what you already run where that fits, with secrets and environment rules.
- 6
Validate on real tasks
We run representative tasks through the workflow with your developers and adjust the rules that did not hold up.
- 7
Document and hand over
A written operating procedure with a named owner and onboarding for the team, so the workflow runs without us. Scope and timeline are agreed in writing before configuration starts.
Is this the right page?
- 1 Assess
- 2 Implement
- 3 Automate
- 4 Build
Choose this page if your developers use or plan to use OpenAI Codex and you want it configured for your existing repository.
- Choose AI-Assisted Development Environment instead if you want the tool-neutral workflow first, or use several tools.
- Choose Development Infrastructure Setup instead if repositories, CI or releases are the bigger gap.
What usually comes next
Not a package — only where it makes sense once this is done.
- AI-Assisted Development Environment
one shared workflow across the tools your team uses
Who you would be working with
- Company · Who you would be working with
- LATYNEX Digital is a service line of Latynex Trade OÜ, a company registered in Estonia (EU). Contact: info@latynexdigital.com.
- How we work · Delivery
- Remote, in English, with the person who would run the project. No local office is implied in any market.
- How we work · Commercial terms
- One scope and one price, agreed in writing before work starts. Your accounts, code and domain stay yours; any access we use is granted by you and can be withdrawn.
There are no client case studies on this page, and none are implied. What LATYNEX has built and runs itself is on the portfolio, each system labelled by stage. Published prices are on the pricing page; anything not listed there is scoped and quoted after review.
Questions
Local Codex or cloud tasks?+
By task. Work that needs your local environment or step-by-step steering suits the local surfaces; a well-specified change that builds and tests from a clean checkout suits a cloud task. We write the guide with you.
Can Codex and Claude Code share instructions?+
Often, through AGENTS.md, which Claude Code's CLAUDE.md can import. Behaviour depends on the tool versions, so we confirm it at assessment.
Are secrets available to the agent in a cloud task?+
Per the vendor's documentation, environment secrets are available during setup and removed before the agent phase, and internet is off by default in that phase. We verify the setup against your project.
Does a sandbox mean we can skip review?+
No. The sandbox limits what the agent can do while it works. Its output still comes back as a diff for your developers to review.
Can administrators lock settings for everyone?+
Where your organisation's setup supports it, yes, through enforced requirements. We check what applies to you.
How long will it take?+
It is scoped after a review of your repository and depends on repository complexity and existing CI/CD. We make no time promises here.