Headsup colors
Glanceable Claude Code and Codex state in your terminal tabs: white=idle, blue=working, orange=waiting. Multi-terminal (iTerm2, WezTerm, AI Power Term), a live status bar with Anthropic usage limits, /sfl and /nil window save-and-restore, and twelve companion skills. macOS only.
npx -y skills add wasulajr/headsup --skill headsup-colorsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Customize the three global tab colors for Claude Code's iTerm2 status hook — idle (fresh session), processing (Claude working), and waiting (Claude needs you). Invoke when the user wants to change any of those three colors ("change waiting color to orange", "idle should be gray", "swap blue for purple while processing"). Edits ~/.claude/hooks/headsup-status.conf, applies the matching color to the current tab immediately, then commits + pushes if ~/.claude/ is a git repository. Title/badge customization is a SEPARATE skill (/headsup-label) — don't handle those here.
SKILL.md
4.5 KB, as published. Nobody here has run it
iTerm2 Color Customization (global)
Edits the three state colors in the GLOBAL hook config. All iTerm2 tabs running claude share these colors; per-tab labels (title + badge) are handled separately by /headsup-label.
Files involved
~/.claude/hooks/headsup-status.conf— global config. Edit this only; do NOT touch~/.claude/hooks/headsup-status.sh(the script has defaults that apply when the conf file is missing — that's the safety net).~/.claude/— may be a git repo (e.g. a personal fork of headsup cloned there directly). After saving, commit + push if.gitis present.
Configurable surface
Three hex values (no leading #):
IDLE_COLOR— fresh session / idle statePROCESS_COLOR— Claude is processing the user's promptWAIT_COLOR— Claude has finished and is waiting on the user
Title and badge are NOT in scope here. If the user asks about title/badge changes during this skill, redirect them to /headsup-label.
Flow
- Read current colors from
~/.claude/hooks/headsup-status.conf. If the file doesn't exist, the script defaults apply (white / blue / yellow). - Show the three current values clearly. Use the user's argument to the skill (if any) as a hint about which color(s) they want to change; otherwise ask.
- Ask only about colors the user wants to change. Accept hex codes OR common color names — translate names to hex yourself (e.g.
red→e74c3c,green→2ecc71,orange→e67e22,purple→9b59b6). - Validate hex — must be 6 hex chars, no
#. Reject 3-char or#-prefixed forms with a one-line correction. - Rewrite the conf file, preserving the existing badge/title function bodies and any other content unchanged. Only modify the
*_COLOR=lines that the user asked about. - Apply the matching color immediately to the current tab. Don't wait for the next session. Only write the color matching Claude's CURRENT state — writing the wrong-state color would visually contradict reality (e.g. don't write the new WAIT_COLOR right now because Claude is currently processing the user's prompt, so the tab should be PROCESS_COLOR). The simple heuristic: if you changed
PROCESS_COLOR, write that one (Claude is processing while this skill runs). If you changedIDLE_COLORorWAIT_COLOR, mention they'll appear at the appropriate future moment but don't write them now.- To write the color: find the parent tty by walking up via
ps -o tty= -p $PPIDuntil a non-??tty appears, then write\033]1337;SetColors=tab=<hex>\007directly to/dev/<tty>.
- To write the color: find the parent tty by walking up via
- Persist the change. Check whether
~/.claude/is a git repository:git -C "$HOME/.claude" rev-parse --git-dir 2>/dev/null- If it is a git repo: commit and push —
git -C "$HOME/.claude" add hooks/headsup-status.conf, commit with a message naming the specific change (e.g. "Switch WAIT_COLOR from yellow to orange"), thengit -C "$HOME/.claude" push origin main. - If it is not a git repo (standard
setup.shinstall copies files directly): the change is already saved to disk and takes effect immediately. Tell the user it's live but not version-controlled — no further action needed.
- If it is a git repo: commit and push —
- Tell the user what changed, 1-2 sentences. If you applied a color immediately in step 6, mention they should see it right now. Otherwise mention which future event will show the new color (SessionStart for idle, UserPromptSubmit for processing, Stop/Notification for waiting).
Notes
- Don't ask permission to commit + push when the git check passes. The user invoked the skill; persistence is the whole point.
- Don't add or remove any other config — only the three
*_COLOR=variables. - If the user wants different colors per session, that's not supported by design (colors are global, labels are per-session). Tell them and offer
/headsup-labelfor per-session distinguishability via the badge instead.