claude-migrate-memory-to-doc

Migrates Claude Code memory into tool-agnostic reference docs readable by Codex and other AI CLIs.

1.4k|216|Updated Oct 22, 2025
One-click install
npx skills add https://github.com/daymade/claude-code-skills --skill claude-migrate-memory-to-doc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: claude-migrate-memory-to-doc
Source: https://github.com/daymade/claude-code-skills/tree/main/daymade-claude-code/claude-migrate-memory-to-doc
Command: npx skills add https://github.com/daymade/claude-code-skills --skill claude-migrate-memory-to-doc

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Claude Code's personal memory lives in a per-project directory that is locked to Claude Code: it is not version-controlled and is invisible to every other AI CLI. When you run Codex, Cursor, or another tool in the same directory, that tool cannot read your user profile, collaboration preferences, or methodology. This Skill migrates the cross-tool-shareable content out of memory into tool-agnostic reference docs, leaving memory as a thin handoff cache.

Core Features & Use Cases

  • Scope-based diagnosis: Classifies every memory file by scope (team rules, cross-tool user profile, temporary handoff) so only the right content migrates, with a privacy check that keeps PII and identity maps out of shared docs.
  • Two-layer architecture: Inlines the few must-hold facts into the CLAUDE.md body (guaranteed to load in both tools), moves detail into ~/.claude/references/user/ hub-and-spoke files, symlinks ~/.codex/AGENTS.md to CLAUDE.md, and raises Codex's 32 KiB project_doc_max_bytes truncation limit.
  • Multi-agent review and empirical verification: Spawns four parallel review subagents (completeness, cross-references, link integrity, duplication), then verifies by actually running codex exec and grepping the session rollout log for the inlined section.
  • Safe memory cleanup: Cleans, thins, or keeps remaining memory files, greps for dangling cross-references before archiving, and soft-deletes to a dated backup outside memory/.
  • Use Case: You have months of accumulated Claude Code memory and just started using Codex in the same projects. Run this Skill to move your profile and preferences into shared docs, wire the symlink, and prove with a real Codex session that the content actually loads.

Quick Start

Migrate my Claude Code memory into tool-agnostic docs so Codex can read my user profile and preferences too.

Frequently Asked Questions about claude-migrate-memory-to-doc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I share Claude Code memory with Codex or other AI tools?

Migrate cross-tool content from the memory directory into ~/.claude/references/user/ files, inline the most critical facts into ~/.claude/CLAUDE.md, and symlink ~/.codex/AGENTS.md to that CLAUDE.md so Codex's global layer injects the same file.

Why doesn't Codex read reference files linked from CLAUDE.md?

Codex does not parse or follow text paths written inside CLAUDE.md; it only auto-injects the doc files themselves along its ~/.codex to git-root to cwd chain. Reference files reached only by a plain-text pointer are never auto-loaded, so critical facts must be inlined.

Why is the second half of my CLAUDE.md missing in Codex?

Codex truncates docs at a default project_doc_max_bytes of 32 KiB, silently dropping the tail of a long CLAUDE.md. Raise the limit in ~/.codex/config.toml and keep the critical user-context section near the top of the file.

Should I delete all my old Claude Code memory after migrating?

No. Classify each file first: migrate cross-tool profile content, thin handoffs that duplicate a source of truth, and keep legitimate session handoffs. Soft-delete migrated files to a dated backup outside memory/ rather than hard-deleting.

Can I migrate memory files containing real names or PII into project docs?

No. Identity mappings and personally identifying information should stay in private memory even when project-relevant, because project docs are version-controlled and shared. Thin such files to a pointer instead of migrating them.

How do I verify Codex actually loads my migrated memory?

Run codex exec --skip-git-repo-check from any directory, extract the session id from the output header, find the matching rollout JSONL, and grep it for your inlined section heading and a back-of-file string. A correct symlink alone is not proof.