{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihyk74lgnokrfszyaljyeb6fway7bdhaz5ujr6v2bqjfhebp2nggq",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mopek67jrof2"
  },
  "path": "/t/add-persistent-user-preference-recall-across-codex-cli-conversations/1378787#post_12",
  "publishedAt": "2026-06-20T06:21:50.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@Patdolitse"
  ],
  "textContent": "Patdolitse:\n\n> the “ambient defaults vs triggered workflows” line is the whole\n>  thing, I think. Skills (and the umbrella-project trick) both need _something to fire\n>  them_ — a recognizable task, an invocation. But review depth, PR tone, verbosity,\n>  language aren’t workflows you trigger; they’re the baseline the agent should already\n>  be standing on before it does anything. The moment you have to remember to invoke\n>  your own defaults, they’ve stopped being defaults.\n>\n> That’s also why the umbrella project rubs wrong — you nailed it. It centralizes\n>  context, but it does it by collapsing the two things that actually want to stay\n>  apart: “how this codebase works” (local, per-repo) and “how I work” (portable,\n>  per-me). Stuffing both into one umbrella just moves the leak around.\n>\n> The layering you keep coming back to — repo instructions → user defaults → per-chat\n>  overrides — is the right shape, and the part I’d stress is that it’s a _precedence_\n>  model, not a merge. User defaults travel with you; repo context stays pinned to its\n>  repo and never bleeds into the next one; a per-chat override wins for that chat only\n>  and doesn’t quietly graduate into a new default. When I built my own version of\n>  this, getting that precedence + the no-leak boundary right was 90% of the value —\n>  the storage part was the easy bit.\n>\n> Whether Codex grows a first-class layer or not, that boundary is the part worth\n>  holding out for.\n\n@Patdolitse I think this distinction is exactly right: defaults should be ambient, not something you have to remember to summon.\n\nSkills 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.\n\nThe repo/user/chat layering also feels like the cleanest mental model:\n\n  * Repo instructions: how this codebase works\n  * User defaults: how I work across codebases\n  * Chat overrides: what is different right now\n\n\n\nAnd 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.\n\nThe 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.\n\nA 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.",
  "title": "Add persistent user preference recall across Codex CLI conversations"
}