Add persistent user preference recall across Codex CLI conversations

Patdolitse:

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.

@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.