Ghostty Config
Skill0 starsChanged 4 months agoMITView on GitHub
Set up, repair, upgrade, and optimize your Ghostty terminal configuration as a declarative, version-controlled file — proven by validating and re-reading it, never a blind write. Use to SET UP a clean commented config (font + Nerd Font, theme, default shell, padding, keybinds) on macOS the robust way (real config in ~/.config, pulled in via a config-file include so it isn't silently overridden), REPAIR a config that won't load or a setting that won't take (split-brain between the Library and ~/.config files, invalid/deprecated keys, a font rendering as tofu, a wrong theme name, reload-vs-restart), UPGRADE by adopting new options after a Ghostty version bump and reconciling deprecated keys, or OPTIMIZE a working config (drop redundant defaults, remove unknown/duplicate keys, prove the font resolves with glyph coverage). Every change is validated with `ghostty +validate-config` and confirmed in effect with `ghostty +show-config`.
In this repository12 other files it gives its agents.
- Brew DoctorSkill
- Credential StoreSkill
- Dev EnvironmentSkill
- DotfilesSkill
- Git SetupSkill
- Identity ProfilesSkill
- macOS DefaultsSkill
- Neovim ConfigSkill
- Runtime VersionsSkill
- Shell SyncSkill
- SSH ConfigSkill
- Terminal ThemeSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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
- Distinctive: line 28
No config file at all → setup.
- Very specific: line 66
Read ~/.config/devenv/config.toml for a [ghostty-config] section before prompting.
- Very specific: line 70
Validate, then confirm in effect: After any edit: ghostty +validate-config must pass, and ghostty +show-config must show the intended value.
- Very specific: line 73
One authoritative file: Keep real settings in ~/.config/ghostty/config.
- Very specific: line 85
Read ~/.config/devenv/config.toml before prompting.
≈ “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.
Files
Ghostty config
Manage the Ghostty terminal config as a declarative, version-controlled
file, so your terminal is reproducible and drift is visible. The golden rule is
verification-first: prove a setting took with ghostty +validate-config (it parses) and
ghostty +show-config (it's actually in effect) — never trust that an edit did what you meant.
Route to a workflow
| The user wants to… | Workflow |
| Stand up a clean, commented config (font, theme, shell, keybinds) — the robust macOS way | reference/setup.md |
| Fix a config that won't load / a setting that won't take (split-brain, bad key, tofu font, wrong theme) | reference/repair.md |
| Adopt new options after a Ghostty update; reconcile deprecated keys | reference/upgrade.md |
| Tighten a working config — drop redundant defaults, kill dup/unknown keys, prove the font | reference/optimize.md |
| Prove a change took (and understand live-reload) | reference/verification.md |
No workflow named? (a bare /ghostty-config) — triage first: run scripts/ghostty_doctor.py,
then route:
split_brain …orvalidate FAIL→ repair.- No config file at all → setup.
in_sync yes→ runscripts/config_audit.py+scripts/font_check.py; anycruft/issues→ optimize, else report clean and stop.
The macOS config-location trap (read this first)
On macOS Ghostty always reads ~/Library/Application Support/com.mitchellh.ghostty/config and
only consults ~/.config/ghostty/config when XDG_CONFIG_HOME is exported — with the Library file
winning. So editing ~/.config/ghostty/config alone often does nothing. The robust, dotfiles-
friendly layout this skill sets up: real config in ~/.config/ghostty/config (chezmoi-tracked),
pulled in by a one-line Library file:
# ~/Library/Application Support/com.mitchellh.ghostty/config
config-file = ~/.config/ghostty/configscripts/ghostty_doctor.py flags the split-brain when the XDG file exists but isn't included.
The scripts (call these, don't re-derive them)
The mechanical commands live in scripts/ as tested, read-only helpers — call
them by name. Ghostty's config is a plain file, so the mutation is a file edit and these scripts
are the verification around it (none writes a config).
| Need | Script |
| Validate + detect the macOS split-brain; which file loads | scripts/ghostty_doctor.py [config] |
| See the resolved config / confirm a change is in effect | scripts/show_effective.py [--default] [key…] |
Prove every font-family resolves + has Nerd-Font glyphs | scripts/font_check.py [config] |
| Audit for dup / redundant-default / unknown keys | scripts/config_audit.py [config] |
Discovery (always run first)
ghostty +version # config keys/deprecations are version-specific
scripts/ghostty_doctor.py # valid? which file loads? split-brain?
ls -la ~/.config/ghostty/config \
~/Library/Application\ Support/com.mitchellh.ghostty/config 2>/dev/null # which files existRead ~/.config/devenv/config.toml for a [ghostty-config] section before prompting.
Core principles
- Validate, then confirm in effect. After any edit:
ghostty +validate-configmust pass, andghostty +show-configmust show the intended value. A change that parses can still be overridden by the Library file (see the trap above). - One authoritative file. Keep real settings in
~/.config/ghostty/config; the Library file is a one-lineconfig-fileinclude. Two files with real content = split-brain; the doctor flags it. - Fonts must resolve and have glyphs. A
font-familyGhostty can't find falls back silently; a face without Nerd-Font glyphs renders prompt icons as tofu.scripts/font_check.pyproves both. - Live-reload, don't restart. Ghostty reloads config with
cmd+shift+,(keybindreload_config) — no relaunch needed to verify. A few options (e.g.command) apply only to new windows/surfaces; say so rather than claiming an open window changed. - Track the config. It's a dotfile — version
~/.config/ghostty/configvia thedotfilesskill (chezmoi) so your terminal is reproducible across machines.
Settings
Read ~/.config/devenv/config.toml before prompting; if a [ghostty-config] section exists, use it
as defaults (precedence: explicit answer this session > config.toml > ask). Had to ask? Offer to
save the answer back. Managed by the devenv skill. Keys honored:
config— path to the real config file (default~/.config/ghostty/config).theme— preferred theme name (validated againstghostty +list-themes).font— preferredfont-family(validated againstghostty +list-fonts).
Boundaries with the other skills
- shell-sync decides which shell is canonical; this skill wires it into Ghostty via
command = <shell> --login. Change the shell in shell-sync, reflect it here. - dotfiles (chezmoi) tracks
~/.config/ghostty/config. runtime-versions / brew-doctor own the tools; this skill only configures the terminal that launches them.
Safety
- Back up before overwriting any config file (timestamped copy).
- Don't silently move the source of truth. Migrating from the Library file to
~/.configchanges what Ghostty reads — confirm direction, and leave the Library file as an explicitconfig-filepointer so the change is visible and reversible. commandsets the default shell. Confirm the shell path exists (command -v fish) before writing it, or Ghostty opens to an error.
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
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.

