| name | codex-session-load |
|---|---|
| description | Load a specific Codex CLI session into the current conversation by session id, given as a rough/possibly-mistyped uuid (e.g. "019edfd4-fbf0-7100-a982-2ab5bdf125fb"). Reads the matching rollout-*.jsonl under ~/.codex/sessions (and ~/.codex/archived_sessions), produces a concise summary of what was asked, done, and changed, and keeps the raw file path on hand to look up exact detail later in the conversation. Use when the user invokes /codex-session-load <id>, says "load codex session <id>", "what happened in codex session <id>", "summarize this codex session", or pastes a Codex session id and asks what it contains. |
Bring one Codex CLI session into context as a compact summary, not a wall of raw JSONL. The point is to load enough to answer questions about that session immediately, while keeping a path back to the raw transcript for anything the summary doesn't cover.
Take whatever id-like string the user gives you (full uuid, partial, or even slightly mistyped — ids get garbled in copy/paste) and run the bundled script:
python3 ~/.claude/skills/codex-session-load/scripts/load_session.py "<id-or-substring>"This searches ~/.codex/sessions/**/*.jsonl and ~/.codex/archived_sessions/**/*.jsonl, first by
exact substring match on the filename, then by fuzzy match against the id portion of the filename
(handles a stray/missing leading character, etc.). It returns one of:
{"status": "ok", "path": ..., "digest": {...}}— exactly one match, parsed.{"status": "ambiguous", "candidates": [...]}— more than one close match. List the candidate files (with their dates/paths) and ask the user which one they meant.{"status": "not_found", ...}— no match. Tell the user and ask them to double check the id, or offer to list recent sessions (ls ~/.codex/sessions/*/*/*/) so they can pick one.
The digest already strips boilerplate (environment_context blocks, AGENTS.md injection, permission
preambles, raw <image> tags) and gives you:
meta— session id, cwd, originator, cli_version, model_provider, start timeuser_messages— the actual things the user asked for, in orderassistant_messages— the model's text repliesfunction_calls— tool/shell/patch invocations (name + truncated arguments)reasoning_notes— any reasoning summaries present
Turn this into a short narrative for the user, in roughly this shape:
- One-line header: project (cwd), date, originator, how many turns.
- Timeline: each real user ask, in order, with a short note on what was done in response
(cross-reference
function_callsnear that timestamp — e.g. "ranapply_patchon X", "pushed to main", "deployed to st3ve"). - Outcome: what shipped / what's still open, if it's evident from the trailing messages.
Keep it tight — a few bullets per turn, not a transcript dump. This summary is what should live in the conversation; don't paste the full raw JSON back to the user unless they ask for it.
Remember the resolved path from Step 1. If the user later asks something the summary doesn't
cover (the exact command that was run, the exact diff, an exact error string), don't re-derive it
from memory — grep the original file for it:
grep -o '"name":"[^"]*"' <path> | sort -u # what tools/commands were invoked
grep -n '<keyword>' <path> # find the line(s) mentioning somethingThen read the matched line(s) with python3 -c "import json; print(json.loads(open(...).readlines()[N]))"
or similar, and answer from that specific event rather than guessing. Treat the summary as the
working context and the file as the source of truth to refer back to on demand.
- Session ids in Codex rollouts look like
019edfd4-fbf0-7100-a982-2ab5bdf125fband appear as the trailing segment of the filename:rollout-<timestamp>-<id>.jsonl. - If several sessions are genuinely about the same id prefix (e.g. resumed/forked sessions), surface all of them rather than guessing — let the user disambiguate.
- This skill only loads context; it does not write anything to the wiki. For mining Codex history
into the Obsidian wiki, use
codex-history-ingestorwiki-agent(/wiki-codex) instead.