{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreienfeh52bdfoqbigw4mdh62z3qirclsbvhili7co5wuzzghc6wita",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mp6hyhcebqf2"
  },
  "path": "/t/add-persistent-user-preference-recall-across-codex-cli-conversations/1378787#post_17",
  "publishedAt": "2026-06-26T07:21:05.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@Patdolitse"
  ],
  "textContent": "@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?”\n\nGlobal 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.\n\nThe two failure modes that matter most are exactly the ones your repo/user/chat model is trying to prevent:\n\n  1. A temporary chat preference silently becoming a standing user default.\n  2. A repo- or project-specific assumption leaking into unrelated work.\n\n\n\nThat’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.\n\nThis layer should be able to answer: where did this instruction come from, why is it active, what outranks it, and when does it expire?\n\nWithout 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.",
  "title": "Add persistent user preference recall across Codex CLI conversations"
}