Repository navigation
Proposal: repo-scoped experience compiler hooks for memory, evals, briefs, and skills #20985
Description
Proposal
I built an OSS companion tool called WorkGraph:
https://github.com/ranausmanai/agent-workgraph
WorkGraph watches local Codex and Claude coding sessions and compiles them into repo-scoped engineering intelligence:
- project journey / milestones
- learned repo rules
- known traps and repeated failure patterns
- eval/check candidates
- reusable skills and task patterns
- future-agent briefs
- AGENTS.md-style instruction suggestions
- a local UI for inspecting the compiled work graph
This is related to memory, but the focus is not raw memory storage. The focus is experience compilation: turning human-agent work into durable, inspectable repo intelligence that future agent sessions can reuse.
Why this matters
Codex sessions generate high-value experience:
- what the user asked
- what the agent tried
- what failed
- what the human corrected
- which files were involved
- which tests or checks proved the fix
- what future agents should avoid
Today much of that disappears into chat history, compaction summaries, or broad memory. Repo-scoped, inspectable compiled memory would reduce repeated mistakes and repeated context explanation, especially for users who work across many repositories.
This also overlaps with existing memory discussions, especially scoped/project memory. The distinction I want to highlight is that the useful unit is often not a single memory note, but a compiled work episode: task → attempts → correction → verification → reusable lesson/eval.
Current reference implementation
WorkGraph is currently an external local-first tool. It works by reading local session artifacts and writing repo-local outputs under .workgraph/.
Current surfaces include:
- CLI:
workgraph start,workgraph stop,workgraph brief,workgraph reuse - Codex skill install: users can ask Codex to start WorkGraph from inside a session
- Claude Code slash command install:
/workgraph - local web UI at
http://127.0.0.1:8787 - repo artifacts such as
journey.md,workgraph.md,known_traps.md,generated_evals.jsonl,repo_rules.md,agent_instructions.md, andtask_templates.md - cross-project reusable skills stored under
~/.workgraph/skills/ - local default compiler, with optional model-backed providers only when explicitly enabled
The goal is not to make Codex depend on WorkGraph. The goal is to explore whether Codex should expose a clean interface so external tools can safely interoperate with Codex around repo-scoped memory and experience compilation.
Requested Codex integration points
I am not opening a PR because the contributing guide says external PRs are invitation-only.
Instead, I would like feedback on whether Codex would consider lightweight extension points for external experience compilers, such as:
- A documented local session transcript/event export path
- A lifecycle hook after session turns, stop, or compaction
- A project-scoped startup brief file that Codex can choose to read
- A way for external tools to provide a relevant repo brief before a new session starts
- A documented schema for repo memory / eval / trap / skill artifacts
- Optional controls for users to inspect, disable, or clear repo-scoped compiled memory
Example output
For a future task, WorkGraph can produce a brief like:
Relevant repo memory:
1. Similar checkout timeout issue was caused by token refresh, not retry count.
2. paymentClient.ts has hidden coupling with auth/session.ts.
3. Always run npm run test:payments after touching checkout.
4. Avoid changing global timeout constants; that caused flaky CI twice.
Related issues
This seems related to long-term and scoped memory discussions, but may be a slightly different surface area because it focuses on compiled session experience and repo-local artifacts rather than only memory storage.
If this direction aligns with the Codex roadmap, I am happy to provide implementation notes, failure cases, schema examples, or a narrower design proposal.
Activity
[-]Proposal: external experience compiler hooks for repo-scoped Codex memory[/-][+]Proposal: repo-scoped experience compiler hooks for memory, evals, briefs, and skills[/+]github-actions commentedon May 4, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ranausmanai commentedon May 4, 2026
Thanks for the duplicate suggestions. I reviewed the related issues and agree this overlaps with parts of them, but I do not think it is an exact duplicate.
How I see the relationship:
/memory. This proposal is adjacent, but focused on compiled work episodes rather than manually managed memory topics.So the smallest version of this proposal might be split into existing issues as:
But the combined product question here is slightly different: should Codex expose a clean extension surface for external repo-scoped experience compilers that turn sessions into memory, evals, traps, briefs, and skills?
If maintainers prefer this to be consolidated into one of the existing issues, I am happy to close this and move the relevant parts there.
etraut-openai commentedon May 4, 2026
Thanks for posting, but this doesn't sound like a feature request for Codex but rather an proposal for something that you want to build on top of Codex.
We generally prioritize feature requests based on community feedback (upvotes). I don't think this feature request will gain any upvotes as it's written. If you're looking for specific functionality that is missing from Codex, please file a new bug report that specifically describes the problem and the functionality you'd like to see.
If you want to discuss general solutions that can be built on top of Codex, the discussion forum in this repo is a better place to post those ideas.
ranausmanai commentedon May 4, 2026
Thank you for guidance, really appreciate this. @etraut-openai .
oxysoft commentedon May 8, 2026
Indexed this hook ticket in the umbrella tracker: #21753
Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.
Ar9av commentedon Jun 14, 2026
For prior art on the skills + hooks side: agent-manual (https://github.com/Ar9av/agent-manual) documents how Claude Code and Gemini CLI handle this today.
Claude Code's closest equivalent is slash commands (
.claude/commands/as Markdown files) combined withagent-type hooks that can spawn subagents with Read/Grep/Glob access. The memory layer is handled externally viaCLAUDE.mdfiles loaded recursively. Gemini CLI added Agent Skills in its extensions system — scoped Markdown procedure files that load on demand rather than into every context window, which is closer to what you're describing here.The key design question the almanac surfaces: skills that load on demand (Gemini's model) vs. always-on instruction files (Claude Code's CLAUDE.md model) vs. hook-triggered subagents (Claude Code's
agenthook type). Each trades token cost against reliability differently.