Blog

Engineering articles about dotfiles, machine provisioning, and WSL.

2026

• Click a toast, land in the right terminal: reconstructing $WINDOWID on WSL Windows Terminal won't tell a WSL shell which window hosts it, so notification clicks can't find their way back; capture the window handle at the one moment it's provably knowable (you're typing into the tab), stamp it on the toast as a protocol link, and a small validated handler focuses the right window and tab across virtual desktops
• Ship the prompt: put a paste-ready agent prompt in your docs readers paste your install steps into a coding agent now, so write the prompt for them: one paste-ready block authored by whoever knows what the artifact actually supports, the three rules that keep it honest, and a ::: prompt container that keeps the copy button and degrades to clean markdown in RSS and llms-full.txt
• Route links by where you are: a virtual-desktop link router for Windows Windows hands every link to one default browser, so it opens in the wrong client's profile; a router that reads the live windows on your current virtual desktop drops each link — web or slack:// — into the instance already there, no URL rules to maintain, with a themed "Choose a desktop" picker as the fallback
• Run multiple isolated instances of any Electron app: the user-data-dir trick identity in Chromium apps is a directory, so one flag gives any Electron app separate sign-ins, windows, and notifications per instance; the shared mechanism, the shared gotchas (stubs, deep links, memory), and where to point the instances
• How to run multiple Slack instances on Windows, macOS, and Linux the workspace switcher shares one window, one notification stream, and one sign-in set; one profile directory per instance via --user-data-dir gives each client a fully separate Slack, with launcher recipes for all three desktops
• One hotkey per client: virtual desktops and workspaces on Windows Windows gives you the desktops but no way to jump to one, fill one, or script one; shortcut hotkeys, the VirtualDesktop module, and per-profile Slack instances close the gaps, combined declaratively in the windows role
• What is Claude Code's auto-compact threshold, and can you change it? not a fixed percentage but the window minus a ~33K-token reserve, so ~83% on 200K and ~97% on 1M, the env vars that move it, why you can't reliably disable it, and how a status line counts down to it
• The agent-ready machine: generated context your agents can trust stop writing agent context and generate it at provisioning time from the data that builds the machine: what's installed, where work lives, what happened recently, three files that cannot drift
• Agent rules are config, not prose agent instructions fork the moment you have two machines or one teammate, so treat them as keyed data overridden per rule, layered personal to project to company, versioned and applied like the rest of your config
• Which account am I? Per-shell context isolation for cloud CLIs gcloud, kubectl, and doctl each keep the current account in one global file, so switching one terminal switches them all; move it into per-shell env vars and each window becomes its own isolated session, safe for parallel work and coding agents
• TOOLING.md: tell your coding agents what's in the toolbox agents discover CLI tools by trial and error, so install a good baseline, scan it on every apply, and hand every agent one generated inventory that never lies
• Git worktrees: parallel checkouts for you and your coding agents what worktrees are, where to put them, the gitignored-state trap, and one .worktrees/ convention shared by humans and Claude Code
• What's the best Claude Code status line? what belongs on the line in what order of importance, how to build it with one shell script, and the tools if you'd rather adopt, the claude role there to provision it
• What's the best dotfiles manager? it depends on what you're actually managing, an honest guide to Stow, dotbot, bare git, yadm, chezmoi, and Nix by scope
• Why a role beats a symlink: idempotent config the Ansible way why writing the settings beats symlinking whole files, and where Dotfiles Pro still symlinks on purpose
• Which shell file runs when: the bash and zsh startup order the login, non-login, interactive, and non-interactive loading order, and where the ~/.profile.d framework hooks in
• chezmoi for the files, Dotfiles Pro for the machine: one repo, a dotpro/ subdir keep chezmoi managing $HOME at the repo root and add provisioning in dotpro/, the playbook installs chezmoi and hands the files back to it
• Keep your raw dotfiles, add a machine: Dotfiles Pro in the same repo plain dotfiles stay committed at the root where stow still works, the playbook sits beside them, and the dotfiles role links only the files in dotfiles_list, no subdirectory needed
• Ubuntu and macOS on one team: a shared setup without a shared OS one dotfiles standard across both operating systems, so collaboration stops depending on whose laptop it is
• Twenty laptops, one installer: closing the day-2 gap with a shared dotfiles collection provisioning a team fleet: the day-0 installer hands off to day-2 apply
• Provision the machine, spec the container: Dotfiles Pro and devcontainers using the collection with devcontainers and Codespaces
• Lens on Windows, gcloud in WSL: GKE authentication across the boundary shims, PATH sourcing, exec env account binding, and WSLENV bridging