As your collection of Codex projects grows, useful knowledge can become trapped inside separate folders. One project may contain a reliable market-data downloader, another a reporting engine, and a third the solution to an authentication problem. When every task sees only one project, Codex cannot easily tell you that the same problem was already solved elsewhere.
A Codex Control Center solves this by giving Codex a common view of multiple independent projects. It is an orchestration layer, not a monorepo. The projects do not have to be merged, and they do not have to share one Git history or one GitHub repository.
One parent workspace
↓
Codex Control Center
↓
Multiple independent projects
↓
Separate Git repositories
↓
Separate GitHub repositoriesThe folder structure might look like this:
C:\AIProjects\
│
├── AGENTS.md
├── Control-Center\
├── Market-Crash-Warning\
│ ├── AGENTS.md
│ └── .git\
├── ETF-Pair-Finder\
│ ├── AGENTS.md
│ └── .git\
├── Crypto-Tax\
│ ├── AGENTS.md
│ └── .git\
├── Blog-Desk\
│ ├── AGENTS.md
│ └── .git\
├── ChatHub\
│ ├── AGENTS.md
│ └── .git\
└── Real-Estate\
├── AGENTS.md
└── .git\This is a design you create manually. Codex does not automatically create, move, clone, or configure these folders and repositories merely because you describe the architecture. You decide which projects belong in the workspace and arrange or attach them yourself.
Why build a Control Center?
Suppose Project A downloads market data and Project B needs the same data. Project C formats reports and Project D needs similar reporting. Project E has already solved an authentication problem that Project F is now encountering. Without cross-project visibility, code and architectural knowledge remain isolated.
A Control Center can let Codex perform read-only work across the collection:
- review projects and compare their architecture;
- find duplicated code and similar implementations;
- identify reusable modules or candidates for a shared library;
- check Git status across repositories;
- spot outdated dependencies or inconsistent practices;
- create cross-project documentation;
- recommend a controlled way to reuse code after approval.
The goal is not unlimited computer access. The better goal is maximum useful visibility plus minimum necessary write permission.
1. Create or arrange the parent folder
On Windows, you can create a parent directory and project folders in PowerShell:
mkdir C:\AIProjects
cd C:\AIProjects
mkdir Control-Center
mkdir Market-Crash-Warning
mkdir ETF-Pair-Finder
mkdir Crypto-Tax
mkdir Blog-Desk
mkdir ChatHub
mkdir Real-EstateIf projects already exist, you can move them under this directory or clone their repositories there. Moving a working project can affect shortcuts, scripts, or tools that rely on its old path, so inspect those dependencies first.
cd C:\AIProjects
git clone <repository-url> Blog-Desk
git clone <repository-url> ChatHubDo not initialize C:\AIProjects as a Git repository unless you intentionally want a monorepo. In the usual Control Center design, the parent has no .git directory, while each child repository does.
C:\AIProjects
NO .git
C:\AIProjects\Blog-Desk
YES .git
C:\AIProjects\ChatHub
YES .git2. Give Codex a view of the projects
There are two practical arrangements, and the available choice can depend on your Codex version and environment.
Open the parent folder: instead of opening only C:\AIProjects\Blog-Desk, open C:\AIProjects. Codex can then see the nested project directories that the workspace and sandbox permit.
Attach several folders to one local Codex project: Codex local projects can be associated with one or more folders. In this arrangement, one folder is primary and the others are secondary. According to OpenAI's current documentation, Codex automatically discovers project files such as AGENTS.md, skills, and configuration from the primary folder; secondary folders can be available for reading and editing, but their project files are not automatically discovered in the same way. You should therefore inspect the instructions in every target project before making a change.
CODEX
│
▼
C:\AIProjects
│
┌──────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Blog-Desk ChatHub ETF-Pair-Finder
│ │ │
▼ ▼ ▼
Git Git Git
│ │ │
▼ ▼ ▼
GitHub GitHub GitHubFilesystem visibility still depends on operating-system permissions, Codex sandbox settings, approval settings, and how the project was opened. Seeing a name in a diagram does not guarantee that a particular Codex task can read or write it.
3. Make permissions the center of the design
Giving Codex visibility into several projects does not mean Codex should automatically change all of them. Think in three conceptual levels. The names below are a planning model, not guaranteed product labels.
Level 1 — Read only
Codex may read files, search code, inspect architecture and Git status, compare projects, and produce reports. It may not edit or delete files, install software, change configuration, commit, or push. This is the recommended default for Control Center analysis.
Level 2 — One-project write
Codex may modify one explicitly named project while treating every other project as reference-only. A useful instruction is: Modify ETF-Pair-Finder only. All other projects are read-only.
Level 3 — Broad administrative access
Codex could potentially modify several repositories, install dependencies, execute commands, commit changes, or push changes—only where the environment and approvals permit. Use this level sparingly. Broad authority multiplies the impact of a mistaken command or misunderstood boundary.
The actual enforcement comes from the Codex sandbox, filesystem permissions, approval policy, connected tools, and the commands you authorize. Written instructions in AGENTS.md guide behavior, but they are not a replacement for real access controls.
4. Write master operating guidance
If you use a parent-folder workspace, a master AGENTS.md can describe the intended operating model:
# Codex Control Center
This directory contains multiple independent software projects.
## Default Mode
READ-ONLY across all projects unless the user explicitly authorizes modifications.
## Project Isolation
Every subdirectory may represent an independent project.
Never assume two projects belong to the same Git repository.
Never merge repositories unless explicitly requested.
## Before Modifying Anything
1. Identify the target project.
2. Read that project's AGENTS.md.
3. Check git status in that repository.
4. Confirm the operation is inside the target project.
5. Preserve unrelated changes.
## Cross-Project Rules
You may inspect projects, search code, compare implementations,
identify reusable modules, find duplication, and recommend improvements.
Do not copy code, modify another project, delete files, move repositories,
or merge repositories without explicit instructions.
## Git and GitHub Safety
Do not commit, push, force push, reset --hard, delete branches,
rewrite Git history, or create or delete remote repositories unless requested.
## Secrets
Never copy or expose .env files, API keys, passwords, access tokens,
private keys, wallet seed phrases, or credentials.
Never transfer secrets between projects.
## Destructive Commands
Do not run destructive commands unless explicitly authorized.
Examples: rm -rf, del /s, git reset --hard, git clean -fd, DROP DATABASE.
## Cross-Project Review Output
For each project report:
1. Project name and purpose
2. Language and framework
3. Git status
4. Major dependencies
5. Reusable modules and duplicate functionality
6. Security concerns
7. Recommended improvementsAGENTS.md acts as operating guidance for Codex, but instruction discovery has boundaries. OpenAI documents a chain that starts with global instructions, then proceeds from the detected project root—typically the Git root—toward the current working directory. If you open a task directly inside a child Git repository, a parent file above that repository's root is not guaranteed to be part of the instruction chain. Verify which instructions apply, and explicitly read the child project's AGENTS.md before changing it.
5. Keep project-specific rules close to each project
A child project can add narrower rules. For example, C:\AIProjects\Crypto-Tax\AGENTS.md might say:
# Crypto Tax Project
This project handles financial and blockchain data.
Do not modify tax calculations without explicit authorization.
Do not delete historical transaction data.
Never expose wallet addresses marked private.
Run tests before proposing calculation changes.
Do not commit or push unless explicitly instructed.The intended hierarchy is:
Master workspace guidance
C:\AIProjects\AGENTS.md
↓
Project-specific guidance
C:\AIProjects\Crypto-Tax\AGENTS.mdCloser instructions can refine or override broader ones when both are in the discovered chain. Because nested Git roots and secondary attached folders can change discovery behavior, do not assume the diagram alone proves which file is active.
6. Use precise Control Center prompts
Build an inventory
Review every project under C:\AIProjects.
Do not modify anything.
For each project report:
- purpose
- language and framework
- whether it is a Git repository
- current Git status
- major dependencies
- last meaningful development area
- obvious technical debt
Then create a summary table.Find reusable code
Search all projects for market-data downloading code.
Do not modify anything.
Identify duplicate implementations, the strongest implementation,
APIs used, caching methods, error handling, and reusable modules.
Recommend whether a shared library would make sense.Compare two projects
Compare Blog-Desk and ChatHub. Read-only.
Compare architecture, database, authentication, APIs, frontend,
deployment, testing, logging, and configuration management.
Do not modify either repository.Authorize one controlled change
Use Market-Crash-Warning as a read-only reference.
Modify ETF-Pair-Finder only.
Do not copy secrets or configuration files.
Before changing anything:
1. inspect both implementations
2. explain the proposed change
3. identify the files that would change
Wait for my approval, then make the approved change only in ETF-Pair-Finder.Check Git health
Check Git status for every repository under C:\AIProjects.
Do not modify anything.
Report modified files, untracked files, current branch,
repositories with pending changes, and clean repositories.
Do not commit or push.7. Create a project registry
A parent-level PROJECTS.md gives both you and Codex a map. It can record purpose and status without combining the repositories.
# Project Registry
| Project | Purpose | GitHub | Status |
|---|---|---|---|
| Market-Crash-Warning | Market risk monitoring | Private repo | Active |
| ETF-Pair-Finder | ETF pair research | Private repo | Active |
| Crypto-Tax | Crypto tax analysis | Private repo | Development |
| Blog-Desk | Blog publishing | Private repo | Active |
| ChatHub | AI/chat application | Private repo | Development |
| Real-Estate | Property analysis | Private repo | Active |Keep this registry descriptive. Do not place credentials, access tokens, private URLs containing secrets, or sensitive personal data in it.
8. Extract shared code only after evidence
After Codex identifies genuinely duplicated and stable functionality, you might eventually create a shared area:
C:\AIProjects\
│
├── Shared\
│ ├── market-data\
│ ├── reporting\
│ ├── logging\
│ └── utilities\
│
├── Project-A\
├── Project-B\
└── Project-C\Do not centralize merely because two files look similar. Different projects may need different data sources, release schedules, security controls, or failure behavior. Use this sequence:
discover duplication
↓
compare implementations
↓
identify stable common behavior
↓
design a clear interface
↓
test each consumer
↓
extract the shared module9. Never create a global secrets bucket
A file such as C:\AIProjects\.env is dangerous because credentials intended for one project could become visible or accidentally reused elsewhere. Prefer project-local secret files:
Project-A\.env
Project-B\.env
Project-C\.envEach project should exclude its secret files with appropriate .gitignore rules. Never put passwords, API keys, cryptocurrency private keys, seed phrases, production credentials, or access tokens in a prompt, AGENTS.md, or PROJECTS.md.
10. Add a read-only dashboard later
An optional Control Center report could summarize repository health in C:\AIProjects\Control-Center\STATUS.md:
PROJECT CONTROL CENTER
Projects: 6
Clean repositories: 4
Repositories with changes: 2
Projects requiring dependency updates: 3
Projects with failing tests: 1
Shared functionality detected:
Market Data
Market-Crash-Warning
ETF-Pair-Finder
Reporting
Crypto-Tax
Real-Estate
Web UI
Blog-Desk
ChatHubGenerate this from read-only inspection first. If you later automate it, define which commands may run, which files may be written, and how failures are reported.
11. The advanced architecture
CODEX CONTROL CENTER
│
┌────────────┴────────────┐
│ │
PROJECT REGISTRY MASTER GUIDANCE
PROJECTS.md AGENTS.md
│ │
└────────────┬────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
PROJECT A PROJECT B PROJECT C
│ │ │
AGENTS.md AGENTS.md AGENTS.md
│ │ │
Git Git Git
│ │ │
GitHub GitHub GitHubThis gives you centralized AI-assisted understanding while preserving repository independence. Each project can keep different dependencies, release processes, access rules, and GitHub permissions.
12. Increase visibility before authority
A Control Center should increase Codex's visibility before it increases Codex's authority.
READ
↓
UNDERSTAND
↓
COMPARE
↓
PROPOSE
↓
USER AUTHORIZES
↓
MODIFY
↓
TEST
↓
REVIEW
↓
COMMIT
↓
PUSHSeparating these stages reduces the chance that a misunderstood request produces unintended changes across several repositories. It also creates clear review points: first approve the plan, then inspect the implementation, then separately decide whether to commit or publish.
13. Know what the Control Center does not provide
Filesystem visibility does not necessarily mean Codex has access to:
- every previous Codex task or ChatGPT conversation;
- every GitHub repository;
- cloud accounts or credentials;
- another Windows account;
- files outside the permitted workspace;
- commands disallowed by the sandbox or approval policy.
Conversational context, filesystem permissions, Git credentials, GitHub permissions, connected applications, sandbox mode, and approval settings are separate controls. Product behavior can also vary by Codex version, operating system, workspace policy, and whether the task runs locally, in a worktree, or in the cloud.
Recommended default configuration
Workspace: C:\AIProjects
Master guidance: C:\AIProjects\AGENTS.md
Registry: C:\AIProjects\PROJECTS.md
Control Center: C:\AIProjects\Control-Center
Repositories: Independent Git repositories
Default access: Read-only
Write permission: One explicitly named project at a time
Git commit: Explicit authorization
Git push: Explicit authorization
Secrets: Project-local and excluded from GitA Codex Control Center does not need to turn every project into one giant repository. The stronger model is a federation of independent projects under one AI-visible workspace. Each project retains its code, Git history, configuration, and security boundaries, while Codex gains enough visibility to understand relationships across the wider environment.
One Codex
↓
Many Projects
↓
Shared Intelligence
↓
Controlled Permissions
↓
Independent Git Repositories