agentleFS
vibeforge1111vibeforge1111/keep-codex-fast/SKILL.md

keep-codex-fast

Skill1.6k starsChanged 6 months agoMITView on GitHub

Use when Codex feels slow or bloated, when local sessions/logs/worktrees/config have grown over time, or when a user wants safe maintenance for Codex Desktop/CLI state. Provides a read-only report by default, backs up before applying changes, archives instead of deleting, normalizes Windows extended paths, prunes dead config projects, rotates large logs, and moves stale worktrees.

1 other project uses a version of this.

Trending

More talk lately.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 4 mentionsJun 2026: 1 mentionJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 1 mentionOct 2026: 1 mentionNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the vibeforge1111/keep-codex-fast repository that our weekly crawl found: only 7 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about vibeforge1111/keep-codex-fast

The biggest 5 of 7 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 7

Talked about on GitHub (7 times).

On GitHub · 7

2 more on GitHub
  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. jscraik/Agent-Skills★ 9same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. About 0 are common, 18 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to inspect and safely maintain local Codex state.

    line 10
  2. Distinctive:

    Write manifests and restore scripts when sessions/worktrees are moved.

    line 20
  3. Distinctive:

    If Codex is running, default to report-only.

    line 21
  4. Very specific:

    Never modify or copy credential files unless the user explicitly asks for that.

    line 22
  5. Distinctive:

    Treat backup folders as private local artifacts because they can contain Codex metadata.

    line 23
  6. Very specific:

    Do not print raw thread IDs, chat titles, local paths, or process paths unless the user asks for details or runs --details.

    line 24
  7. Distinctive:

    Before applying changes, tell the user to create handoff docs for active repo chats they may continue.

    line 25
  8. Distinctive:

    Before archiving any active repo chat the user may want to continue, recommend creating a comprehensive handoff doc plus a reactivation …

    line 26
  9. Distinctive:

    Do not archive old-but-important active repo chats until the user either confirms a handoff exists or confirms they do not need one.

    line 27
  10. Distinctive:

    Run the bundled script in report mode:

    line 40
  11. Distinctive:

    Before applying changes, recommend that the user create handoffs for all active repo chats they may continue.

    line 56
  12. Very specific:

    If the user wants to apply the recommended maintenance, ask them to close Codex or use --wait-for-codex-exit, then run:

    line 60
  13. Distinctive:

    Ask whether the user wants a recurring report-only reminder:

    line 72
  14. Distinctive:

    no reminder if they prefer manual maintenance

    line 75
  15. Distinctive:

    Keep only the last 7-10 days of non-pinned chats active.

    line 94
  16. Distinctive:

    Use handoff docs for important old threads.

    line 95
  17. Distinctive:

    Start fresh threads from handoff docs instead of repeatedly resuming giant chats.

    line 96
  18. Distinctive:

    Run weekly maintenance if Codex is used daily across many repos/terminals.

    line 97
  19. Distinctive:

    When in doubt, leave a chat active or ask the user.

    line 99
  20. Distinctive:

    Treat title/preview repair as metadata repair only.

    line 100
  21. Very specific:

    Use references/handoff-template.md when the user wants a concrete template.

    line 124
  22. Distinctive:

    Add a reactivation prompt at the top or bottom:

    line 161

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Keep Codex Fast

Use this skill to inspect and safely maintain local Codex state. The goal is to reduce local drag without surprising the user or losing continuity.

Primary principle: preserve continuity before applying changes. For active repo chats the user may continue, recommend a comprehensive handoff document and reactivation prompt before archiving anything.

Safety Rules

  • Inspect before mutating.
  • The first run must be report-only. Report mode must not write files, create backups, move folders, or change local Codex state.
  • Back up before applying changes. Use --backup-only when the user wants backups without moving or changing local state.
  • Archive or move files instead of deleting them. Do not permanently delete user chats, logs, worktrees, memories, skills, plugins, or automations.
  • Write manifests and restore scripts when sessions/worktrees are moved.
  • If Codex is running, default to report-only. Apply changes only after Codex is closed or when the user explicitly accepts waiting for Codex to exit.
  • Never modify or copy credential files unless the user explicitly asks for that. Back up memory/skill/plugin/automation files before touching local state.
  • Treat backup folders as private local artifacts because they can contain Codex metadata. Do not ask users to publish or share backups unless they have reviewed them first.
  • Do not print raw thread IDs, chat titles, local paths, or process paths unless the user asks for details or runs --details.
  • Before applying changes, tell the user to create handoff docs for active repo chats they may continue.
  • Before archiving any active repo chat the user may want to continue, recommend creating a comprehensive handoff doc plus a reactivation prompt.
  • Do not archive old-but-important active repo chats until the user either confirms a handoff exists or confirms they do not need one.

Mental Model

There are three modes:

  • Inspect: report-only, no writes.
  • Maintain: normal --apply; backs up, archives old sessions, moves stale worktrees, rotates logs, prunes dead config, and normalizes paths. It does not trim thread title/preview metadata.
  • Optional repair: --apply --repair-thread-metadata-bloat; shortens oversized SQLite display title/preview metadata after backup. The rollout transcript stays intact.

Default Workflow

  1. Reassure the user: the first run is read-only, privacy-safe, and the skill archives instead of deleting when changes are later applied.
  2. Run the bundled script in report mode:
python scripts/keep_codex_fast.py
  1. Summarize:
    • active session size
    • archived session size
    • largest active sessions
    • thread metadata bloat: active title/preview character totals, max title/preview lengths, and over-limit counts
    • stale worktree candidates
    • log size
    • bad Windows \\?\ path counts
    • config project prune candidates
    • top Node/dev processes
  2. Before applying changes, recommend that the user create handoffs for all active repo chats they may continue. Explain that handoffs let them archive heavy chats and resume from docs in fresh threads.
  3. Identify large/old active repo chats that may still matter. For each one the user wants to continue, create or update:
    • a repo-local handoff doc
    • a reactivation prompt that can start a fresh chat without losing the thread
  4. If the user wants to apply the recommended maintenance, ask them to close Codex or use --wait-for-codex-exit, then run:
python scripts/keep_codex_fast.py --apply --archive-older-than-days 10 --worktree-older-than-days 7
  1. Verify after applying:
python scripts/keep_codex_fast.py
  1. Ask whether the user wants a recurring report-only reminder:
    • weekly for heavy Codex use across many repos/terminals
    • biweekly for lighter use
    • no reminder if they prefer manual maintenance

If the user wants automation and the Codex app automation tool is available, create only a recurring report/reminder automation. Do not recommend recurring mutating maintenance, because automation cannot know whether the user created handoffs. The prompt must say not to pass --apply, not to archive/move/prune/rotate/normalize/delete/mutate local state, and to remind the user that manual apply should happen only after handoffs are confirmed and Codex is closed.

What Apply Does

  • Backs up important metadata to ~/Documents/Codex/codex-backups/keep-codex-fast-*.
  • Archives old non-pinned sessions to ~/.codex/archived_sessions/.
  • Normalizes Windows extended paths like \\?\C:\... inside local SQLite text fields.
  • Prunes missing/temp project blocks from config.toml and writes UTF-8 without BOM.
  • Moves stale worktrees to ~/.codex/archived_worktrees/.
  • Rotates logs_2.sqlite* into ~/.codex/archived_logs/ only when above the threshold.
  • Reports heavy Node processes without killing them.
  • Reports pathological active thread titles and first_user_message previews. It only repairs them when the user explicitly opts in with --repair-thread-metadata-bloat.

Report mode does none of those mutations. It only prints counts and pseudonymous candidates. Use --details when raw IDs, titles, or paths are needed for diagnosis.

Recommended Policy

  • Keep only the last 7-10 days of non-pinned chats active.
  • Use handoff docs for important old threads.
  • Start fresh threads from handoff docs instead of repeatedly resuming giant chats.
  • Run weekly maintenance if Codex is used daily across many repos/terminals.
  • Offer weekly or biweekly report-only reminders after the first successful apply; do not assume the user wants recurring maintenance.
  • When in doubt, leave a chat active or ask the user. Never archive a chat that is pinned, current, or explicitly marked as still needed without a handoff.
  • Treat title/preview repair as metadata repair only. The full rollout transcript remains in the session JSONL; bounded SQLite fields are for list/navigation display.

Thread Metadata Bloat

Codex Desktop can become slow when threads.title or threads.first_user_message stores a full prompt/history-sized value instead of a display title or preview. This affects the thread list/navigation path before the UI renders anything.

The script reports active thread count, total title/preview characters, maximum title/preview length, active titles over the configured title limit, and active previews over the configured preview limit and over 10k characters.

Normal apply mode reports metadata-bloat candidates but does not repair them. If the user explicitly opts in, after backups and only when Codex is not running, run:

python scripts/keep_codex_fast.py --apply --repair-thread-metadata-bloat

That bounds active threads.title and threads.first_user_message values. Defaults are 120 characters for titles and 240 characters for previews. It also appends repaired titles to session_index.jsonl, matching current upstream name-update storage, so reconciliation/name lookup does not immediately prefer the old full-message fallback.

The targeted repair manifest stores the old full title/preview values so the change can be reversed. Treat thread-metadata-repairs.jsonl, restore-thread-metadata.py, and the whole backup folder as private local artifacts.

This is a local maintenance workaround for metadata bloat. It does not solve app renderer hydration of very large rollout histories; that needs upstream staged/paged thread loading.

Handoff Doc + Reactivation Prompt

For important active repo chats, create a handoff before archiving. Prefer a repo-local path such as docs/codex-handoffs/YYYY-MM-DD-topic.md or a user-approved docs location.

Use references/handoff-template.md when the user wants a concrete template.

A handoff document converts an old chat into durable project memory. It should let a fresh Codex thread continue after reading the repo and the handoff, without needing the original chat history.

Offer this prompt for each active repo chat the user may want to continue:

Create a comprehensive handoff document for this repo/session before I archive Codex history.

Include:
- repo/path and branch
- current goal
- what we already completed
- files touched or investigated
- commands/tests already run
- known errors, warnings, or failing checks
- open decisions
- constraints, user preferences, and do-not-touch areas
- the next 3-7 concrete steps

Also include a reactivation prompt I can paste into a fresh Codex chat so it can continue from this handoff without relying on the old chat context.

Save the handoff in a sensible repo-local place like docs/codex-handoffs/YYYY-MM-DD-topic.md unless this repo already has a better handoff location.

The handoff should capture:

  • repo/path and branch
  • current goal
  • what was already done
  • key files touched or investigated
  • commands/tests already run
  • known failures or warnings
  • open decisions
  • next 3-7 concrete steps
  • any constraints, user preferences, or "do not touch" areas

Add a reactivation prompt at the top or bottom:

We are continuing from this handoff. Read this document first, inspect the current repo state, verify what still applies, and continue from the next steps without assuming the old chat context is available.

Automation Reminder Prompt

Offer this after the first report/apply/verify cycle:

Use $keep-codex-fast to create a recurring Codex maintenance reminder.

Schedule it weekly if I use Codex heavily, or biweekly if that seems safer.

The reminder should:
- run the keep-codex-fast report first
- never pass --apply or run mutating maintenance automatically
- never archive, move, prune, rotate, normalize, delete, or mutate local Codex state
- remind me to create comprehensive handoff docs and reactivation prompts for active repo chats before any manual apply
- summarize active session size, archived session size, extended path candidates, old session candidates, worktree candidates, log size, and top Node/dev processes
- report heavy Node/dev processes without killing them
- tell me that manual apply should only happen after I confirm handoffs exist or are not needed and Codex is closed

Anti-Patterns

Avoid these behaviors:

  • deleting sessions, logs, worktrees, memories, plugins, or skills permanently
  • applying changes while Codex is actively writing the DB
  • archiving important repo chats before creating handoff docs
  • treating active history size as "bad" without checking whether the user needs continuity
  • treating preview metadata repair as deletion of the actual rollout transcript
  • killing Node/dev processes automatically
  • rewriting config.toml without a backup and parse check
  • writing UTF-8 TOML with a BOM on Windows
  • promising speed gains as universal fact; frame improvements as local-state maintenance results
  • making users feel like they did something wrong by using Codex heavily

User-Facing Caution

Tell users this does not permanently delete chats, worktrees, or logs. It moves them into archive folders and writes restore helpers. The only removed content is stale metadata, such as project entries pointing to folders that no longer exist, and even that happens after backing up config.toml.

Also tell users that thread title/preview bloat repair is not part of normal apply. Normal use only reports title/preview bloat. Recommend --repair-thread-metadata-bloat only as an optional extra when the report shows large metadata payloads and the user understands that SQLite display metadata will be shortened while the real transcript remains in rollout JSONL.

Also tell users backup folders can contain private local Codex metadata, including old thread titles and first-message previews. They should keep backups local and avoid publishing or sharing them unless they have reviewed what is inside.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.