codex-auto-memory不是通用笔记软件，也不是云端记忆服务。 它的目标是：在今天的 Codex CLI 上，用本地 Markdown、紧凑 startup injection、按需 topic file 读取与 companion runtime，尽可能复现 Claude Code auto memory 的可观察产品契约。
三个要点，快速定位：
- 它做什么 — 每次 Codex 会话结束后，自动把有用的信息提取出来，写进本地 Markdown 文件，下次启动时注入给 Codex，让它"记得"你的项目。
- 它怎么存 — 全部是本地 Markdown 文件，放在
~/.codex-auto-memory/，你随时可以查看、编辑、纳入 Git 审查。 - 它和 Claude 的关系 — 这是一个 companion CLI，目标是在 Codex 上复现 Claude Code auto memory 的工作方式。不是 Claude 官方产品，不涉及云端。
Claude Code 已经公开了一套相对清晰的 auto memory 产品契约：
- AI 会自动写 memory
- memory 以本地 Markdown 保存
MEMORY.md是启动入口- 启动时只读取前 200 行
- 细节写入 topic files，按需读取
- 同一仓库的不同 worktree 共享 project memory
/memory用来审查和编辑 memory
而今天的 Codex CLI 已经有不少有价值的基础能力，但还没有公开同等完整的 memory product surface：
AGENTS.md- multi-agent workflows
- 本地 persistent sessions / rollout logs
- 本地
cam doctor/ feature output 里可见的memories、codex_hookssignal
codex-auto-memory 的价值，就是在官方 native memory 还没有稳定公开之前，先提供一条干净、可审计、可迁移的 companion-first 路线。
适合：
- 想在 Codex 中获得更接近 Claude-style auto memory 工作流的用户
- 希望 memory 完全本地、完全可编辑、可以直接放进 Git 审查语境里的团队
- 需要在多个 worktree 之间共享 project memory，同时保留 worktree-local continuity 的工程流
- 希望未来迁移到官方 native memory 时，不需要重建用户心智模型的维护者
不适合：
- 想把它当通用知识库、笔记软件或云端同步服务的人
- 期待现阶段直接替代 Claude
/memory全部交互能力的人 - 需要账号级个性化记忆或跨设备云端记忆的人
| 能力 | 说明 |
|---|---|
| 自动 memory 同步 | 会话结束后从 Codex rollout JSONL 中提取稳定、未来有用的信息并写回 Markdown memory |
| Markdown-first | MEMORY.md 与 topic files 就是产品表面，而不是内部缓存 |
| 紧凑启动注入 | 启动时只注入紧凑的 MEMORY.md 索引和 topic refs，不做 eager topic loading |
| worktree-aware | project memory 在同一 git 仓库的 worktree 间共享，project-local 仍保持隔离 |
| session continuity | 临时 working state 与 durable memory 分层存储、分层加载 |
| reviewer surface | cam memory / cam session / cam audit 为维护者和 reviewer 提供可核查的审查入口 |
| 能力 | Claude Code | Codex today | Codex Auto Memory |
|---|---|---|---|
| 自动写 memory | Built in | 没有完整公开契约 | 通过 companion sync flow 提供 |
| 本地 Markdown memory | Built in | 没有完整公开契约 | 支持 |
MEMORY.md 启动入口 |
Built in | 没有 | 支持 |
| 200 行启动预算 | Built in | 没有 | 支持 |
| topic files 按需读取 | Built in | 没有 | 部分支持，启动时注入路径引用并按需读取 |
| 跨会话 continuity | 社区方案较多 | 没有完整公开契约 | 作为独立 companion layer 支持 |
| worktree 共享 project memory | Built in | 没有公开契约 | 支持 |
| inspect / audit memory | /memory |
无等价命令 | cam memory |
| native hooks / memory | Built in | Experimental / under development | 当前只保留迁移 seam |
cam memory 当前是 inspection / audit surface：它会暴露真正进入 startup payload 的 quoted index files、startup budget、按需 topic refs、edit paths，以及 --recent [count] 下的 recent durable sync audit。
这些 recent sync events 来自 ~/.codex-auto-memory/projects/<project-id>/audit/sync-log.jsonl，只覆盖 sync flow 的 applied / no-op / skipped 事件，不包含 manual cam remember / cam forget。
如果主 memory 文件已经写入，但 reviewer sidecar（audit / processed-state）没有完整落盘，cam memory 会尽力暴露一个 pending sync recovery marker，帮助 reviewer 识别 partial-success 状态；该 marker 只会在同一 rollout/session 后续成功补齐时清理，不会被不相关的成功 sync 顺手抹掉。
显式更新仍通过 cam remember、cam forget 或直接编辑 Markdown 文件完成，而不是提供 /memory 风格的命令内编辑器。
git clone https://github.com/Boulea7/Codex-Auto-Memory.git
cd Codex-Auto-Memory
pnpm installpnpm build
pnpm link --global链接之后，
cam命令就可以在任意目录使用了。
cd /你的项目目录
cam init这会在项目根目录生成 codex-auto-memory.json（跟踪到 Git），并在本地创建 .codex-auto-memory.local.json（默认 gitignored）。
cam run每次会话结束，cam 会自动从 Codex 的 rollout 日志里提取信息并写入 memory 文件。
cam memory # 查看当前 memory 文件和 startup budget
cam session status # 查看 session continuity 状态
cam remember "Always use pnpm instead of npm" # 手动记录偏好
cam forget "old debug note" # 删除过时记录
cam audit # 检查仓库有没有意外的敏感内容| 命令 | 作用 |
|---|---|
cam run / cam exec / cam resume |
编译 startup memory 并通过 wrapper 启动 Codex |
cam sync |
手动把最近 rollout 同步进 durable memory |
cam memory |
查看 startup 实际加载的 index files、按需 topic refs、startup budget、edit paths，以及 --recent [count] 下的 durable sync audit |
cam remember / cam forget |
显式新增或删除 memory |
cam session save / load / status / clear |
管理独立的 session continuity layer，并在需要时暴露 pending continuity recovery marker |
cam audit |
做仓库级隐私 / secret hygiene 审查 |
cam doctor |
检查当前 companion wiring 与 native readiness posture |
cam audit: 仓库级的 privacy / secret hygiene 审计。cam memory --recent [count]: durable sync audit，查看 recentapplied/no-op/skippedsync 事件，不混入 manualremember/forget。cam session save|load|status: continuity audit surface，查看最新 continuity diagnostics、latest rollout 与 latest audit drill-down；其中load/status的文本输出会额外显示 compact prior preview（排除 latest，并收敛连续重复项），三个命令的--json都会继续返回 raw recent audit entries；当 continuity Markdown 已写入但 audit 失败时，还会暴露 pending continuity recovery marker。
local-first and auditableMarkdown files are the product surfacecompanion-first today, native migration seam tomorrowsession continuity与durable memory明确分离
flowchart TD
A[启动 Codex 会话] --> B[编译 startup memory]
B --> C[注入 quoted MEMORY.md 与 topic refs]
C --> D[运行 Codex]
D --> E[读取 rollout JSONL]
E --> F[提取 durable memory 操作]
E --> G[可选 continuity 总结]
F --> H[更新 MEMORY.md 与 topic files]
G --> I[更新 shared / local continuity]
- 官方公开文档尚未给出完整、稳定、等价于 Claude Code 的 native memory 契约；本地
cam doctor --json也仍把memories/codex_hooks视为未进入 trusted primary path 的 signal - 本地观察与 source inspection 可以作为 migration signal，但不能直接升级成稳定产品契约
- 因此项目默认仍然坚持 companion-first，直到官方文档、运行时稳定性和 CI 可验证性都足够强
Durable memory：
~/.codex-auto-memory/
├── global/
│ └── MEMORY.md
└── projects/<project-id>/
├── project/
│ ├── MEMORY.md
│ └── commands.md
└── locals/<worktree-id>/
├── MEMORY.md
└── workflow.md
Session continuity：
~/.codex-auto-memory/projects/<project-id>/continuity/project/active.md
<project-root>/.codex-auto-memory/sessions/active.md
更完整的结构与边界说明，请看架构文档。
当前公开可依赖的项目状态：
- durable memory companion path：可用
- topic-aware startup lookup：可用
- session continuity companion layer：可用
- reviewer audit surfaces：可用
- native memory / native hooks primary path：未启用，仍非 trusted implementation path
- companion CLI
- Markdown memory store
- 200-line startup compiler
- worktree-aware project identity
- 初始 reviewer / maintainer 文档体系
- 更稳的 contradiction handling
- 更好的
cam memory/cam session审查体验 - continuity diagnostics 与 reviewer packet 继续打磨
- 为未来 hook bridge 保留 seam
- 在官方 native memory / hooks 足够稳定后提供 native adapter
- 可选 GUI / TUI browser
- 更强的跨会话 diagnostics 与 confidence surfaces
- 贡献指南：CONTRIBUTING.md
- License：Apache-2.0
如果你在 README、官方文档和本地运行时观察之间发现冲突，请优先相信：
- 官方产品文档
- 可复现的本地行为
- 对不确定性的明确说明
而不是更自信但证据不足的表述。