Add persistent user preference recall across Codex CLI conversations

Codex Codex CLI
,
1

Summary
I would like Codex CLI to remember recurring user preferences across new conversations, especially formatting and workflow preferences that I currently have to restate each time. Examples include my preferred GitHub commit message style and my preferred PR description structure. This would make Codex feel more continuous and reduce repeated setup instructions at the start of new chats.

Problem
At the moment, Codex CLI behaves as if each new conversation starts from zero. Even when I repeatedly use the same preferred format for common tasks, I still have to remind Codex in each new chat. This creates unnecessary repetition and slows down routine workflows.

A common example is when I ask Codex to:

  • generate a GitHub commit message
  • generate a PR description from a PR title

In both cases, I often have to restate my preferred format, even though those preferences are stable and reused across many sessions. When prior preferences are not retained, Codex becomes less efficient for recurring engineering workflows.

Proposed Feature
Add persistent user preference recall across Codex CLI conversations.

This could allow Codex to remember lightweight working preferences such as:

  • preferred GitHub commit message format
  • preferred PR description structure
  • preferred documentation layout
  • preferred response style for recurring tasks

The feature should allow Codex to apply remembered preferences by default in new chats, while still letting the user override them whenever needed.

Why This Would Help
Persistent preference recall would create continuity across separate Codex sessions. That would help the product:

  • reduce repetitive user instructions across chats
  • improve workflow efficiency for recurring tasks
  • make Codex feel more like a persistent assistant than a stateless tool
  • support users with stable personal or team conventions
  • lower friction in common engineering tasks such as commits, PR descriptions, and docs

Expected Benefits
This feature would improve the product in several ways.

First, it would save time by removing the need to repeat the same instructions in every new chat. Second, it would improve consistency by making Codex more likely to produce outputs in the user’s established preferred format. Third, it would create a smoother user experience by carrying forward useful context between sessions. Finally, it would make Codex CLI better suited to repeated real-world engineering workflows, where conventions are often stable over time.

Suggested Design Principles
The feature would be strongest if it is:

  • easy for users to set and update
  • transparent about when remembered preferences are being applied
  • optional rather than automatic without visibility
  • scoped appropriately at user level and possibly repo level
  • easy to override in any single conversation
  • lightweight for common preferences, not overly complex

Conclusion
Persistent preference recall across Codex CLI conversations would be a small but high-value improvement. It would reduce repetition, improve consistency, and make Codex more effective for users who rely on stable formatting and workflow conventions across multiple sessions. This would strengthen usability and make Codex feel more adaptive to real working habits.

2

have you tried setting up an AGENTS.md file?

3

AGENTS.md helps, but it is not the same thing as what I’m asking for.

My request is about persistent preference recall across new Codex CLI conversations, especially for user-level habits that repeat across repos and sessions. An AGENTS.md file is repo-scoped and project-specific. That makes it useful for things like build commands, test workflow, architecture constraints, and repo conventions, but it is a weaker fit for personal preferences such as:

  • my preferred commit message style
  • my default PR description structure
  • my preferred response format for recurring tasks

There are a few reasons I see them as different:

  1. AGENTS.md is tied to a repository, while many preferences are tied to the user.
  2. It requires creating and maintaining files in each repo, even when the preference is global.
  3. It is better for project instructions than for lightweight personal defaults.
  4. It does not really solve continuity across unrelated projects or fresh workspaces.

So yes, AGENTS.md is a reasonable workaround today, and I would probably use it for repo-level conventions. But I still think there is a product gap: Codex CLI should ideally support explicit, persistent user preferences separately from repo instructions.

A strong model would be:

  • AGENTS.md for repository or team rules
  • persistent profile/preferences for user-level defaults
  • per-chat overrides when needed

That separation would be cleaner and closer to how engineers actually work.

4

Hi @adrian.a.adewunmi

Thanks for the clear write-up, the distinction you’re making between repo-level instructions (AGENTS.md) and user-level preferences across sessions is spot on.

Right now Codex CLI is stateless, so things like commit style or PR structure need to be reintroduced or handled per-repo, which creates the friction you’re describing.

The idea of separating repo conventions, user defaults, and per-chat overrides makes a lot of sense and fits well with real workflows.

~SD

5

Hi ~SD,

Thanks for confirming this. That split between repo conventions, user defaults, and per-chat overrides feels like the missing piece to me.

AGENTS.md works well for codebase-specific guidance, but it’s not a good place for persistent personal working preferences that should follow the user across repos and sessions. Re-stating things like commit style, PR format, or review preferences each time adds avoidable overhead.

A layered model like:

  • repo-level instructions
  • user-level defaults
  • chat-level overrides

would map much more cleanly to how people actually work in practice.

Appreciate the thoughtful response.

Best wishes,

Adrian

6

@adrian.a.adewunmi yeah this is the exact gap — AGENTS.md tells the tool “how this project works” but nothing about “how I like to work.”

I hit the same wall and ended up building an MCP server that keeps user stuff and project stuff separate. So my commit format, PR style, language preference — that follows me everywhere. But project-specific context stays in that project folder, doesn’t leak into other repos.

When I open a brand new repo in Codex it already knows how I work without me repeating anything. That’s the part that really cuts the friction.

Your layered idea (repo instructions → user defaults → per-chat overrides) is spot on. MCP makes this pretty easy to wire up since any compatible client reads from the same local store.

7

@Patdolitse @OpenAI_Support Yes, this is exactly the split I want too. Repo instructions should describe the codebase, not become a dumping ground for personal workflow preferences.

Keeping user defaults portable while leaving project context local feels like the right model. Commit style, PR tone, review depth, preferred language, and similar defaults should follow the developer across repos. Architecture notes, commands, domain context, and team conventions should stay tied to the repo.

MCP can be a good fit for this, especially if you want the same preferences available across multiple AI clients through one local source of truth. For a single tool, though, a user-level instructions layer would probably be simpler and easier to debug.

The important part is the layering: repo instructions, user defaults, and per-chat overrides. That would make Codex feel much less repetitive without blurring boundaries between projects.

8

You can use skills to define additional workflows and instructions, then reuse them across any projects where they are helpful.

I ended up with a set of skills that I use almost all the time, so I created a template for new projects.

The missing piece is getting Codex to use these skills automatically in regular chats, or to integrate them automatically into new projects.

As far as I understand the current direction in this area, the suggested solution is to have one main project act as an umbrella for everything else, including new projects.

9

I think skills are a useful part of the answer, especially for repeatable workflows. I use them more like reusable capability modules than personal defaults, though.

For me, the gap is still a first-class layering model. Skills work well when there is a recognisable trigger or workflow, but preferences like review depth, PR tone, commit style, language, verbosity, and default assumptions are more like ambient defaults. I would rather not encode every preference as a skill and then rely on Codex deciding when to invoke it.

An umbrella project also feels like a workaround. It can centralise context, but it blurs the boundary between project-local knowledge and user-level behaviour. I would prefer something closer to:

1. User defaults: portable personal preferences.

2. Repo instructions: project-specific context and commands.

3. Skills: reusable workflows or domain capabilities.

4. Chat overrides: temporary direction for the current task.

Skills are great when I want to say, “use this workflow.” User defaults are better for “this is how I generally like to work.” Both are useful, but they solve different problems.

10

@adrian.a.adewunmi the “ambient defaults vs triggered workflows” line is the whole
thing, I think. Skills (and the umbrella-project trick) both need something to fire
them — a recognizable task, an invocation. But review depth, PR tone, verbosity,
language aren’t workflows you trigger; they’re the baseline the agent should already
be standing on before it does anything. The moment you have to remember to invoke
your own defaults, they’ve stopped being defaults.

That’s also why the umbrella project rubs wrong — you nailed it. It centralizes
context, but it does it by collapsing the two things that actually want to stay
apart: “how this codebase works” (local, per-repo) and “how I work” (portable,
per-me). Stuffing both into one umbrella just moves the leak around.

The layering you keep coming back to — repo instructions → user defaults → per-chat
overrides — is the right shape, and the part I’d stress is that it’s a precedence
model, not a merge. User defaults travel with you; repo context stays pinned to its
repo and never bleeds into the next one; a per-chat override wins for that chat only
and doesn’t quietly graduate into a new default. When I built my own version of
this, getting that precedence + the no-leak boundary right was 90% of the value —
the storage part was the easy bit.

Whether Codex grows a first-class layer or not, that boundary is the part worth
holding out for.

11

For most of what was mentioned, a good read of codex documentation would solve the issue. Briefly:

  1. Codex allows storing instructions (skills/agents) on 2 levels:
  • globally in codex
  • per repo
  1. Repeated prompts can be stored by you and reused however you need (do it just by stirring your files wherever you want, or use cool things like wisprflow snippets)
  2. External memory solutions like MCP servers, your own tools+instructions, etc.

For simple memory I would look into something like MunninDB or “second brain” concept (many have it built as an MCP server).

Codex custom instructions doc to read:

Custom instructions with AGENTS.md – Codex | OpenAI Developers Custom instructions with AGENTS.md – Codex | OpenAI Developers

12

@Patdolitse I think this distinction is exactly right: defaults should be ambient, not something you have to remember to summon.

Skills are great for recognisable tasks: “write a migration,” “review this PR,” “generate tests,” “use this framework pattern.” But things like review strictness, tone, preferred verbosity, risk tolerance, and how much explanation I want are not tasks. They are operating assumptions. If I have to invoke them, they are no longer defaults; they are just another workflow.

The repo/user/chat layering also feels like the cleanest mental model:

  • Repo instructions: how this codebase works
  • User defaults: how I work across codebases
  • Chat overrides: what is different right now

And I agree the important part is precedence, not just storage. A chat override should win temporarily. A repo instruction should never leak into another repo. A user default should travel with me without needing to be copied into every project. This boundary is what makes the system trustworthy.

The umbrella-project workaround is useful, but it blurs ownership of context. It solves “where do I put this?” while making “who should this apply to?” less clear. For me, that second question is the real product problem.

A first-class user-default layer would make Codex feel much less like something I configure repeatedly and more like an agent that actually knows how I prefer to work.

13

Agreed that a lot of this is covered once you map the Codex surfaces correctly. The docs make the split clearer than the mental model people often start with:

  • AGENTS.md for durable instructions, globally or per repo
  • skills for reusable workflows that should trigger on a task
  • MCP for external memory/tools/context
  • memories for lightweight carried-forward context, where enabled
  • snippets/custom saved prompts for repeated phrasing or commands

The nuance I’d still preserve is that these solve slightly different problems. A skill is great when there’s a recognisable workflow. AGENTS.md is better for baseline behaviour: review tone, verbosity, repo conventions, preferred commands, etc. MCP or a “second brain” setup is better when the agent needs to retrieve external context rather than carry it in the prompt.

So I think the practical answer is not “one memory layer,” but using the right scope: global Codex instructions for how I work, repo AGENTS.md for how this codebase works, skills for repeatable workflows, and MCP/memory for recall. This gets pretty close to the precedence model people are asking for, without needing an umbrella project that mixes personal defaults with repo context.

14

@adrian.a.adewunmi nailed it — defaults are operating assumptions, not tasks, and the repo/user/chat layering is the right mental model. One thing I’d add to the “isn’t this already solved if you map the surfaces correctly?” point: the surfaces (global/repo AGENTS.md, skills, MCP, memories) solve storage and scope placement. What they don’t solve is enforcement — AGENTS.md is static text the model may or may not honor on a given turn, and nothing stops a per-chat override from quietly graduating into a standing default, or a repo instruction from bleeding into the next repo. The hard 10% isn’t “where do I put it,” it’s making precedence + the no-silent-graduation + no-cross-repo-leak boundary a guarantee rather than a hope. That’s what’s worth a first-class layer.

15

Yes, currently this has not been implemented in the way @adrian.a.adewunmi is describing it.

My suggestion to use a master project to provide personal preferences to individual projects is just an idea for a workaround. I think it can work well across quite a few use cases, but it is definitely not the same as a central preference setting.

Following this conversation, I just wanted to add one small detail that may be helpful when working with agents: there can be several agents.md files inside a project. For example, a large monorepo can benefit from this.

Agents are trained to always read the nearest agents.md file. This is another way to stay in control. Codex, for example, re-reads agents.md after a context compaction.

16

One implementation detail I would want in a first-class preference layer is that every remembered preference is a scoped record, not just another instruction blob.

Something like: scope (global / repo / subdirectory / task), source, created-at, last-confirmed-at, expiry or review policy, and conflict behavior. Then the agent can show “I am applying these three preferences in this run” before acting, and it becomes possible to reject stale or cross-repo leakage.

That also keeps AGENTS.md useful for durable repo behavior, while avoiding the silent promotion problem where a one-off chat preference becomes a permanent default.

17

@Patdolitse I think this distinction is exactly the one that matters: the issue is less “where can I store this?” and more “what guarantees does the system give me once it is stored?”

Global instructions, repo AGENTS.md, skills, MCP, memories, and chat context all provide places to put intent. But defaults need more than storage. They need lifecycle and enforcement: explicit promotion, clear precedence, auditability, and containment.

The two failure modes that matter most are exactly the ones your repo/user/chat model is trying to prevent:

  1. A temporary chat preference silently becoming a standing user default.
  2. A repo- or project-specific assumption leaking into unrelated work.

That’s why I don’t think the hard part is just mapping the surfaces correctly. Skills are great for recognisable tasks, and AGENTS.md is useful for repo-local operating context. But user defaults are ambient operating assumptions, so they need a first-class policy layer around them.

This layer should be able to answer: where did this instruction come from, why is it active, what outranks it, and when does it expire?

Without that, we’re still relying on the model to infer and respect boundaries turn by turn. With it, the repo/user/chat distinction becomes something trustworthy instead of just a convention.

18

@VeitB I believe that’s a helpful clarification, especially the point about multiple AGENTS.md files in a project.

I agree the master-project approach is a reasonable workaround for some workflows, but I think the distinction from earlier still matters: it helps with reuse of preferences, while a central preference layer would solve ownership, precedence, and lifecycle more explicitly.

The nearest-AGENTS.md behavior is a good example of scoped control done well. In a monorepo, it gives the repo a way to say: “these rules apply here, not everywhere.” This maps neatly onto the repo/user/chat model: repo instructions can be local and nested, user defaults should travel across repos, and chat overrides should stay temporary.

So I’d see these as complementary rather than competing mechanisms:

  • nested AGENTS.md for local codebase/module behavior
  • user defaults for cross-project working preferences
  • chat overrides for temporary exceptions

The missing piece is making those layers visible and enforceable enough that users can trust which one is active at any moment, without a workaround blurring ownership of the context.

19

Have you seen the Chief of Staff approach?

The idea is to have one main thread that spawns new threads. If the chief thread has access to your preferred instructions for different types of work, it can pass the relevant instructions along to new threads, including threads inside projects.

What I am trying to say is that this is a limitation, and people have already built different approaches to work around it.

Hope this helps!

20

@adrian.a.adewunmi That’s the right reframe — once defaults need lifecycle and enforcement, the question stops being “where do I store this” and becomes “what does the system guarantee once it’s stored.” Your four — explicit promotion, precedence, auditability, containment — are the actual bar.

In my own implementation, I found those mapped pretty directly to concrete mechanisms:

  • explicit promotion — a preference can’t graduate itself. Moving from a provisional/one-off preference to a standing default takes an explicit confirm step, so a chat-level preference doesn’t quietly become permanent.
  • precedence + containment — user defaults and project context live in separate stores with a hard write boundary. Repo context is only eligible inside its explicit project scope, so isolation doesn’t depend on the model remembering the rule.
  • expiry + auditability — records carry source/provenance and freshness policy, so “where did this come from, why is it active, and when should it lapse” has an answer you can inspect.

And your last line is exactly the bar: trustworthy instead of just a convention. Storage surfaces — AGENTS.md, skills, memories — don’t clear that bar by themselves. The guarantee has to live a layer below the prompt, not only inside it.