Proposal: repo-scoped experience compiler hooks for memory, evals, briefs, and skills

Resolved 💬 6 comments Opened May 4, 2026 by ranausmanai Closed May 4, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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, and task_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:

  1. A documented local session transcript/event export path
  2. A lifecycle hook after session turns, stop, or compaction
  3. A project-scoped startup brief file that Codex can choose to read
  4. A way for external tools to provide a relevant repo brief before a new session starts
  5. A documented schema for repo memory / eval / trap / skill artifacts
  6. 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.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20952
  • #20920
  • #19758
  • #20115
  • #20603

Powered by Codex Action

ranausmanai · 2 months ago

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:

  • #20952 asks for a stable session JSONL schema. WorkGraph would benefit from that, but this issue is broader: what external compilers can do with session experience after export.
  • #20603 asks for hook capability/session-exit hooks. That is one possible integration point, but not the whole proposal.
  • #20115 asks to archive/export conversations into a project folder. WorkGraph uses session artifacts as evidence, but then compiles them into repo rules, evals, traps, briefs, and reusable skills.
  • #19758 is about Codex memory directory architecture and /memory. This proposal is adjacent, but focused on compiled work episodes rather than manually managed memory topics.
  • #20920 is about an LLM wiki/index over broad ChatGPT/Codex history. WorkGraph is narrower: repo-scoped agent coding sessions -> actionable engineering assets for future agents.

So the smallest version of this proposal might be split into existing issues as:

  1. stable session export/schema (#20952)
  2. lifecycle hooks (#20603)
  3. repo/project artifact export (#20115)
  4. scoped memory architecture (#19758)

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 contributor · 2 months ago

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 · 2 months ago

Thank you for guidance, really appreciate this. @etraut-openai .

oxysoft · 2 months ago

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 · 1 month ago

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 with agent-type hooks that can spawn subagents with Read/Grep/Glob access. The memory layer is handled externally via CLAUDE.md files 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 agent hook type). Each trades token cost against reliability differently.