You write your Codex rules in Markdown. Then a reasonable question appears: “If I sign in on another computer with the same OpenAI account, do those rules come with me?”
The answer is not automatically.
ChatGPT Custom Instructions and Memory are account-centered personalization. Codex files such as $CODEX_HOME/AGENTS.md and ~/.codex/config.toml are files in the environment where Codex runs.
Same company, different address for the rules.
AGENTS.md has no built-in teleport spell.
1. Same account does not mean the same local configuration
| Item | Main location or scope | Should another PC be assumed to get an identical copy automatically? |
|---|---|---|
| ChatGPT Custom Instructions | ChatGPT account | Account-centered |
| ChatGPT Memory | ChatGPT personalization | Used as account context |
$CODEX_HOME/AGENTS.md |
Codex environment file | No |
$CODEX_HOME/AGENTS.override.md |
Codex environment file | No |
~/.codex/config.toml |
Local Codex configuration | No |
Repository AGENTS.md |
Project file | Yes, if Git transfers it |
OpenAI describes Codex CLI as a cross-platform local software agent operating on the user’s machine. Its published prompt-building description says Codex reads ~/.codex/config.toml, AGENTS files under $CODEX_HOME, and instruction files from the Git/project root down to the current working directory.[1]
That is a “read the files that exist here” design.
2. ChatGPT is much closer to “the account remembers this”
OpenAI says Custom Instructions apply immediately to all chats and are available on Web, Desktop, iOS, and Android.[2]
Memory is managed through ChatGPT personalization and can retain useful context from chats, files, and connected apps so you do not need to repeat the same information constantly.[3]
OpenAI also says that when multiple ChatGPT accounts are switched, chats, memory, history, billing, workspaces, and settings stay separate by account.[4]
So “ChatGPT personalization follows the account” is a useful mental model.
That does not mean every theme, notification, operating-system permission, or platform-specific setting is identical everywhere.
Account-centered is accurate. “Every setting in the universe syncs” is not.
3. Codex AGENTS.md is a job-site manual, not an account memory
Think of AGENTS.md less like a profile field and more like an operating procedure on a workshop wall.
If PC A contains:
~/.codex/AGENTS.md
- run tests before finishing
- preserve unrelated existing changes
- never force-push
those characters belong to PC A’s filesystem unless you synchronize them through some other mechanism.
Signing into PC B with the same OpenAI account does not justify assuming that PC A’s ~/.codex directory will materialize there.
The account answers “who is using Codex?”
The local files answer “how should Codex work in this environment?”
4. A repository AGENTS.md can travel because Git carries it
If you commit project/AGENTS.md, the rule file becomes part of project history.
Remote Git project
└── project/
├── AGENTS.md
├── src/
└── docs/
↓ clone / pull
PC A PC B
└── project/ └── project/
└── AGENTS.md └── AGENTS.md
This is not OpenAI account synchronization.
It is Git moving a versioned file.
For project-specific build commands, test procedures, coding conventions, forbidden operations, and review requirements, that is often ideal. The rules travel with the code that needs them.
No more moving the factory while leaving the operating manual in the old building.
5. Codex can layer broad and increasingly specific instructions
OpenAI’s technical description says user instructions are aggregated from multiple sources. It includes AGENTS.override.md and AGENTS.md under $CODEX_HOME, then looks through folders from the Git/project root toward the current working directory. Project documentation is subject to a default 32 KiB limit.[1]
That makes a layered design natural:
~/.codex/AGENTS.md
rules for every project
project/AGENTS.md
rules for this project
project/server/AGENTS.md
extra rules for this area
This is easier to maintain than one giant Markdown constitution that tries to govern everything.
6. Multiple computers: local copies are sensible, but keep one source of truth
A robust setup can look like this:
Git: codex-config/global-AGENTS.md ← source of truth for common rules
│
┌──────┴──────┐
↓ ↓
PC A ~/.codex/AGENTS.md PC B ~/.codex/AGENTS.md
Git: project/AGENTS.md ← project source of truth
↓ clone/pull ↓ clone/pull
PC A project/AGENTS.md PC B project/AGENTS.md
If one machine fails, other copies and Git history remain. A replacement machine can be rebuilt from versioned configuration.
But do not make every local copy an independent master.
Otherwise you eventually get:
PC A = v18
PC B = v16 plus one mysterious edit
PC C = v11 “probably the latest?”
That is not redundancy. That is archaeology.
7. Synchronization is not the same thing as backup
Three identical files do not automatically make a good backup.
If a synchronization tool instantly propagates an accidental deletion to every machine, congratulations: the deletion now has excellent availability.
A resilient setup needs:
- one clearly identified source of truth;
- usable copies on other machines;
- version history that lets you recover from a bad change.
Git is useful for plain-text configuration because it can support all three.
Do not put API tokens, private keys, cookies, passwords, or personal information in that repository.
A backup strategy that backs up the security incident itself is not a strategy.
8. Practical placement guide
| Information | Good home | Why |
|---|---|---|
| Persistent ChatGPT response preferences | Custom Instructions | Account-oriented personalization |
| Conversational context you want ChatGPT to carry forward | Memory | Designed for ChatGPT personalization |
| Rules every local Codex project should follow | $CODEX_HOME/AGENTS.md |
Broad local Codex scope |
| Local Codex behavior settings | ~/.codex/config.toml |
Documented Codex configuration source |
| Build, test, and safety rules for one project | repo/AGENTS.md |
Versioned together with the project |
| Extra rules for one subdirectory | repo/subdir/AGENTS.md |
More specific local context |
| Recoverable master copy of global Codex rules | A safe versioned Git location | Easy to reproduce across machines |
Different layers solve different problems. You do not need to dump every ChatGPT preference into Codex or every repository procedure into ChatGPT Memory.
9. Common failure modes
A new PC makes Codex behave differently
Check whether the old machine’s ~/.codex/AGENTS.md and config.toml were actually migrated.
The model may not have developed a new personality. You may simply have left its operating manual behind.
The same project behaves differently on different PCs
If project rules are maintained manually on every machine, configuration drift is expected. Put project rules in the repository where practical.
The global file was edited independently on three PCs
Now all three files claim to be the latest.
You did not create three backups. You created three political parties.
API tokens were committed “for easy recovery”
Do not do that. Keep secrets in proper secret-management or environment mechanisms.
10. The clean model: account layer, machine layer, Git layer
[ChatGPT account layer]
Custom Instructions / Memory
↓
Web / Desktop / Mobile
[Codex machine layer]
PC A ~/.codex/AGENTS.md + config.toml
PC B ~/.codex/AGENTS.md + config.toml
↑
optionally synchronized from a safe source of truth
[Project Git layer]
project/AGENTS.md
↓ clone / pull
PC A / PC B / compatible execution environments
The final answer is simple once the layers are separated.
For ChatGPT, “the account remembers” is a useful model. For local Codex Markdown, “this machine has the file” is the safer model. Repository-level AGENTS.md can follow the project through Git.
Copies on several PCs can improve resilience. Pair that redundancy with one versioned master.
AGENTS.md cannot teleport.
Git can buy it a train ticket.
Official sources
Sources
- OpenAI, “Unrolling the Codex agent loop openai.com
- OpenAI Help Center, “ChatGPT Custom Instructions help.openai.com
- OpenAI Help Center, “Memory FAQ help.openai.com
- OpenAI Help Center, “Use multiple accounts with account switching help.openai.com
