skills/codex-session-maintenance/SKILL.md
Maintain local Codex Desktop/App state when Codex feels slow, session history is heavy, logs or worktrees are large, or the user asks to inspect, archive, clean up, rotate, hand off, reset, or speed up Codex sessions. Use for inspect-first, backup-first local state maintenance: measure hotspots, create handoffs for useful long sessions, archive stale sessions/worktrees, rotate logs, prune clearly dead project paths only after backup and confirmation, and report concrete verification. Do not use for application code performance, model prompt tuning, live conversation compaction, process killing, automation scheduling unless requested, or deleting user data.
npx skillsauth add plimeor/agent-skills codex-session-maintenanceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Keep local Codex state lightweight, recoverable, and explainable.
The operating model:
A good maintenance pass:
Treat local Codex state as user data.
For inspect, never mutate files. For cleanup, first report proposed actions and get confirmation.
If Codex is running, inspect only. Do cleanup after the app is closed so local state and databases are not touched from two places.
Never delete sessions, logs, worktrees, config, databases, memories, skills, plugins, or automations unless the user explicitly asks for deletion after a backup exists.
Do not archive pinned, current, recent, useful-without-handoff, or ambiguous sessions. Do not move dirty or externally registered git worktrees unless the user confirms the exact worktree and safe move method.
inspect: run inventory, report hot spots, and stop.cleanup: inspect, propose actions, confirm Codex is closed, create backup or manifest, execute confirmed moves only, then verify.handoff: identify useful long sessions, create handoff docs and starter prompts, then ask before archiving.automation: design the repeatable maintenance contract only; do not schedule anything until the user confirms.Start with one broad inventory:
$CODEX_HOME, falling back to ~/.codex when unsetDeep-dive only into the top hot spots or paths above obvious thresholds. Read metadata first: path, size, modified time, git status, manifest/config parseability, and database integrity when relevant.
Do not read session JSONL contents unless creating a handoff. Search again only when a proposed mutation depends on missing facts, paths conflict, state looks ambiguous, or the user asks for comprehensive cleanup.
CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
du -sh "$CODEX_HOME"/* 2>/dev/null | sort -h
find "$CODEX_HOME/sessions" -type f -name '*.jsonl' -size +10M -print 2>/dev/null
find "$CODEX_HOME/log" -type f -size +50M -print 2>/dev/null
find "$CODEX_HOME/worktrees" -mindepth 1 -maxdepth 1 -type d -mtime +10 -print 2>/dev/null
ps aux | rg -i '[c]odex'
ps aux | rg -i 'node|bun|vite|next|webpack|tsx'
Do not kill processes automatically. Report candidates with command, PID, age, and why they look relevant.
Common directories:
$CODEX_HOME/sessions
$CODEX_HOME/archived_sessions
$CODEX_HOME/worktrees
$CODEX_HOME/archived_worktrees
$CODEX_HOME/log
$CODEX_HOME/memories
$CODEX_HOME/skills
$CODEX_HOME/plugins
$CODEX_HOME/automations
On Windows, watch for duplicate path forms such as C:\... and \\?\C:\.... Normalize only when you can prove both forms refer to the same location.
Prefer archiving or rotating over deleting. Back up important files before cleanup.
Create a timestamped backup outside the active state tree, for example:
~/.codex-maintenance/backups/YYYYMMDD-HHMMSS/
Back up small important state before changing anything: config files, global state or session indexes, local databases, memories, skills, plugins, automations, and manifests that map sessions, projects, or worktrees.
For large session files or worktrees, a manifest plus archive move is usually better than a duplicate copy. The manifest should include original path, size, modified time, and planned destination.
If a database is present and sqlite3 is available, verify it before and after:
sqlite3 path/to/state.sqlite 'PRAGMA integrity_check;'
Stop if the database cannot be opened or the integrity check fails.
Propose pruning clearly dead project paths only after backup. Execute config changes only after confirmation. Preserve unknown entries and report them instead of guessing.
Before archiving a long session that still matters, create a concise handoff:
# Codex Handoff: [short task name]
## Goal
- [What this session was trying to accomplish]
## Current State
- [What is done]
- [What remains]
## Decisions
- [Stable decisions worth preserving]
## Files And Artifacts
- [Important paths, branches, PRs, docs, or generated outputs]
## Commands And Results
- [Commands that matter and their observed results]
## Risks Or Blockers
- [Anything the next session must not miss]
## Restart Prompt
[A ready-to-paste prompt for a fresh Codex session]
Preserve decisions, current state, evidence, and the next prompt. Do not turn handoffs into transcripts.
Sessions from the last 7-10 days are usually too recent to archive, but age is only a heuristic. Keep pinned, current, ambiguous, or useful sessions. Archive old non-pinned sessions only by moving them to the archived-session location and recording the original path in a manifest. Do not edit session JSONL contents as a cleanup tactic.
For worktrees, inspect each candidate with git status --short when it is a git repository. Keep dirty worktrees unless the user confirms a specific archive action. If a directory is a registered git worktree, prefer the repository's safe worktree move mechanism; stop if you cannot verify it.
For logs, rotate oversized old logs by moving them to an archive folder. Leave the active log path available so Codex can recreate fresh logs. Do not truncate a log while Codex is running.
For inspect, report commands and observed sizes/processes, and state that no files changed.
For cleanup, verify backup exists, manifest entries match moved paths, config parses if config changed, databases open if touched or nearby, dirty worktrees were not moved, and before/after sizes or counts changed as expected.
For handoff, verify the handoff file exists and includes Goal, Current State, and Restart Prompt.
For automation, do not claim scheduling verification unless the user approved scheduling and it actually happened.
Report in this shape:
## Codex Session Maintenance
Mode:
- [inspect / cleanup / handoff / automation]
Observed hot spots:
- [path] - [size / age / reason]
Proposed actions:
- [only for actions not yet confirmed]
Completed actions:
- [what was archived, rotated, pruned, or left unchanged]
Not touched:
- [live, pinned, dirty, ambiguous, or out-of-scope state]
Backups and manifests:
- [backup path, manifest path, or "not created because this was inspect-only"]
Verification:
- [commands/checks actually run and results]
Residual risk:
- [anything left for the user to decide]
Stop and ask for confirmation when Codex is running and the next step would mutate local state; a candidate session appears pinned, current, or important but lacks a handoff; a worktree is dirty or externally registered; a database integrity check fails; cleanup would delete rather than archive; or the target Codex state directory cannot be identified confidently.
tools
Decide whether and how to use authorized sub-agents, then coordinate delegated work while preserving the main agent's context. Use when the user asks for orchestration, parallel agents, delegation, background workers, context isolation, or when another skill needs delegated research, review, implementation, or verification. Owns host-policy checks, delegation packets, non-overlap, report verification, and stop rules. Do not use to bypass tool policy, infer user authorization, or add coordination overhead to simple single-threaded tasks.
development
Use before finalizing a non-trivial answer, recommendation, review, or decision to reconsider it and raise its quality, especially when shallow reasoning, context inertia, false framing, overconfidence, unfit analogy transfer, or an obvious-but-missed defect could distort the result. Trigger especially before applying external evidence, familiar frameworks, or comparisons to the user's specific request, and when the user asks to reconsider, double-check, take a second look, or sanity-check an answer. Reconsider the draft against its most likely failure mode, and use independent scrutiny only when it is useful and authorized.
development
Review concrete code plan drafts, specs, diffs, and implementation shapes. Use for code-review requests, serious code-plan design critique, and judging whether a proposed direction is sound. Prioritize solution direction, premise validity, logic chain, constraints, alternatives, design shape, contracts, tests, local fit, and actionable findings. Near miss: use code-plan to create or revise plans; use code-scope-gate for pre-spec scope shaping.
development
Write evidence-backed coding plans for implementation, debugging, refactoring, migrations, design parity work, and long-running agent tasks. Use when defining, clarifying, refining, or validating a development plan, /goal prompt, implementation approach, scope and non-goals, work sequence, acceptance criteria, regression evidence, verification strategy, or stop condition. Near miss: use code-review when judging an existing diff, spec, or already drafted plan rather than drafting or revising a plan. Also use when the user says `design twice` after a plan and wants an APOSD-style second-design pass over the completed plan.