CoreyMSchafer/dotfiles: a macOS workstation setup you are expected to edit

A macOS workstation setup that rewrites your shell

CoreyMSchafer/dotfiles exists to reproduce one person's development machine on another. The repository is described as scripts and configuration files to set up a development environment for macOS, and the list of what `install.sh` triggers is explicit: symlinks for dotfiles such as `.zshrc` and `.aliases`, the macOS-specific `macOS.sh`, Homebrew plus the manifests `packages.txt`, `apps.txt` and `fonts.txt` through `brew.sh`, and Visual Studio Code configuration with `vscode-extensions.txt` through `vscode.sh`. The target reader is a macOS developer who wants the same shell, prompt and editor defaults as the author and who is willing to edit the scripts first. The author is direct about this: the setup is built around his own workflows, and forking is the intended path rather than running the scripts unchanged.

Backup-then-symlink and the ~/.dotfiles_backup/ convention

The interesting mechanism is how existing files are treated. Each step checks the current state before changing anything, and any file that a symlink would replace, an existing `.zshrc` or a VS Code `settings.json` for instance, is first moved into a timestamped folder under `~/.dotfiles_backup/`. The timestamp is the point. Earlier backups are never overwritten, so a second run does not bury the copy made before the first one. The scripts also describe themselves as safe to re-run, since steps that are already done get skipped. `helpers.sh` is listed as the shared home for the logging, backup-then-symlink and manifest helpers used by both the macOS and Linux scripts, and that shared file is what keeps the behaviour consistent between the two installers.

Manifest files and the four local exception lists

Install decisions live in plain text lists: `packages.txt`, `apps.txt`, `fonts.txt` and `vscode-extensions.txt`. Fonts are split in two, because the `fonts/` folder holds fonts Homebrew does not carry, in desktop formats installed on every OS plus `.woff2` for web projects. Machine-specific deviations have their own mechanism. A `.private` file, created empty by `install.sh` and never uploaded to version control, holds per-machine exceptions, and the name of an item installed deliberately on one machine only goes into `MANIFEST_LOCAL_PACKAGES`, `MANIFEST_LOCAL_APPS`, `MANIFEST_LOCAL_FONTS` or `MANIFEST_LOCAL_EXTENSIONS` as a space-separated list. The stated purpose is narrow and useful: a manifest diff should report such an item as intentional rather than as a stray. A separate drop-in folder, `~/.config/zsh/*.zsh`, is sourced last by `.zshrc` and holds anything machine-local or not meant for every fork.

Running install.sh on a fresh Mac

The documented path is three commands. Clone the repository first:

git clone https://github.com/CoreyMSchafer/dotfiles.git ~/dotfiles

Then move into the directory you just created:

cd ~/dotfiles

And run the installer:

./install.sh

On a brand-new Mac the first clone pops a dialog asking to install the Xcode Command Line Tools, because macOS ships a `git` stub that requests them. Click Install, wait for it to finish, then re-run the clone. That order is deliberate, since the install cannot begin until the tools that download it exist. There is also a non-interactive form, useful on a test machine:

./install.sh --no-input

It skips every prompt: computer name, git identity, the GitHub login and the sign-in pauses. Those prompts are the ones that would write machine identity into your git config, so the flag is the one to reach for on a disposable or shared machine.

Where the backup guarantee stops

The gap in the safety story is stated plainly: not everything can be backed up. System settings changed via `defaults write` and installed or upgraded software have no backup mechanism. So the timestamped folder under `~/.dotfiles_backup/` covers shell and editor files only, while two of the things the installer does, changing system defaults and installing Homebrew packages, sit outside it. There is a third, smaller effect the author calls less serious but potentially annoying: the Desktop background gets set to the image used in the tutorials, because this is the script used to prepare machines he records on. The warning that changes may be irreversible without a fresh installation of the operating system therefore points at defaults and installed software, not at the dotfiles themselves.

Windows and Ubuntu installers are separate ports

The macOS scripts are not the only entry points. The Windows 11 port lives in `windows/` and uses winget, PowerShell 7 and Windows Terminal, with `install.ps1`, `winget.txt` and a `settings/` folder holding the PowerShell profile plus the Terminal color scheme and defaults. The Ubuntu port, which also covers WSL2 on Windows, lives in `ubuntu/` with its own `install.sh` and `apt.txt`. The `skills_ai.txt` list of AI coding-agent skills, installed through `npx skills`, is applied by both `brew.sh` and `windows/install.ps1`, so that one is shared across operating systems even though the package managers are not. Each port carries its own README, and that is the only documentation the top-level page points to for those platforms.

Contributions are welcome only when they match the author's taste

Governance here is narrow and stated rather than implied. The author says he likely will not accept pull requests unless they align closely with his personal preferences and the way he uses the environment, while corrections for obvious errors in the scripts would be welcome. There are no GitHub releases, so there is no tagged artifact to install and the clone is the only entry path, and the last push was on 2026-10-19. The licence is MIT, held in LICENSE-MIT.txt, so reuse of the configuration carries the usual attribution obligation. For a team, the practical reading is that this is a starting point to fork rather than an upstream to depend on, since a change you need may never be merged.

Editorial conclusion

CoreyMSchafer/dotfiles suits a macOS developer who wants a fast route to a complete shell and editor environment and is willing to read and edit install.sh before running it. It does not suit teams that need an upstream installer they do not intend to maintain, since the author says pull requests outside his personal preferences are unlikely to be accepted. Check what the scripts touch first: `defaults write` calls and Homebrew installs have no backup, while only symlinked files land in `~/.dotfiles_backup/`.

Frequently asked questions

Official sources

1. CoreyMSchafer/dotfiles on GitHub
2. Issues
3. License: MIT
4. README