Skills

Keep Codex Fast

Use when Codex feels slow or bloated, when local sessions/logs/worktrees/config have...

Install

npx skills add vibeforge1111/keep-codex-fast --skill keep-codex-fast -g -a claude-code -y
Category
Engineering
Updated
6mo ago
License
MIT
Context cost
Mediumabout 2,970 tokens
Runs scripts
No, instructions only

What it does

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.

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:

Read the whole SKILL.md on GitHub

More in Engineering