hironow/dotfiles: The Dotfiles Repo That Treats Humans and AI as Different Operators

A multi-OS control plane for Mac, Linux, dev containers, and cloud workspaces, with pinned toolchains, build-time provisioning, and explicit agent-aware shell behavior.

10 min read • View on GitHub • More from hironow

A wide control-room scene with a Mac laptop on the left, a container build chamber in the center, and a cloud workspace screen on the right. Two operator badges, one human hand and one mechanical hand, feed into a single command line to show that the same environment must serve both people and AI agents. — This repo treats the shell as shared infrastructure. Humans and agents both pass through the same control plane, but they do not get identical treatment.

Key Takeaways

This repo treats identity as part of environment management, so human operators and AI agents can follow different shell policies without fragmenting the toolchain.
Its core promise is parity across Mac, Linux, dev containers, and remote workspaces, with one source of truth feeding every surface.
The strongest engineering choice is build-time provisioning plus explicit pinning, which reduces drift before a container or workspace ever starts.
Compared with traditional dotfiles, the repo behaves more like personal platform engineering than shell customization.

The shell knows who is typing

Most dotfiles try to make a laptop feel familiar. This one tries to make a person plus agent workflow behave predictably across machines. The unusual move is simple to miss: shell aliases can carry RUNOPS_ACTOR_TYPE=ai-agent, so downstream tools know whether the command came from a human or an automated operator.

I run a solo-operated, human-on-the-loop agentic engineering ecosystem: agents build, gates verify, a human approves. Most of what follows is its public surface.

hironow, Creator/Maintainer · hironow (hironow) · GitHub

That distinction matters because policy can now follow intent. Logging, prompts, or guardrails can branch based on actor type instead of pretending every shell session is the same. It is a small variable with a large design consequence.

Three environments, one truth

The same intent resolves through different paths depending on host, build stage, and actor type. The diagram makes parity visible instead of implicit.

Approach	Parity	Agent awareness	Supply-chain hardening	Learning curve
Traditional Bash/Stow dotfiles	Low	None	Usually manual	Low
chezmoi	Medium	Limited	Good secret handling	Medium
Nix/home-manager	High	Indirect	Strong declarative control	High
hironow/dotfiles	High	Explicit	Strong by default	Medium

The point is not that every layer is duplicated. It is that the repo keeps a single mental model while letting the runtime differ. Host provisioning, container build steps, and workspace setup all converge on the same toolchain and shell behavior.

install.sh is a dispatcher, not a bootstrap dump

case "$DOTFILES_OS" in
  darwin)
    step_macos
    ;;
  linux)
    step_linux
    ;;
  mingw|msys)
    step_windows
    ;;
esac

That branch structure is the point. Instead of forcing one universal path, the installer respects the platform boundary and routes to the correct provisioning logic. It keeps host-level setup separate from container-level setup, which is exactly what you want when the same repo has to survive on macOS, Linux, and Windows native.

The architecture reads less like a script and more like a dispatcher. That is a better fit for a repo that expects multiple execution surfaces and multiple operator types.

Build-time provisioning beats startup-time drift

A close-up pipeline where a package passes through a fingerprint gate, then an attestation checkpoint, before being locked into a vault labeled mise. A narrow side channel shows a quarantined release path waiting before entry, emphasizing trust and delayed adoption. — This is where the repo gets serious. It moves trust checks earlier in the pipeline, so the environment is constrained before the shell starts depending on it.

import_apt_key_with_fingerprint() {
  # verify the key fingerprint before trust
  :
}

gh attestation verify ...
sha256sum -c just.sha256

This is the repo's supply-side engine. Installing tools during docker build is more deterministic than waiting for container startup, and the fingerprint pinning plus attestation checks reduce the risk of pulling in the wrong binary at the wrong time.

For a personal setup, the hardening is unusually mature. It is trying to make the machine boring in the exact places where dotfiles usually become fragile.

mise is the version anchor

Version strategy	Stability	Freshness	Agent tooling fit	Operational cost
System packages only	Medium	Medium	Low	Low
Ad hoc global installs	Low	High	Low	Low
mise with quarantine	High	Balanced	High	Medium
Pinned per-project binaries	High	Low	Medium	High

The config/mise/config.toml file does more than select versions. It encodes a release policy, including a seven-day quarantine for newer releases and special handling for claude-code. That tells you the repo is optimized for active churn, not just frozen reproducibility.

Placing mise activate at the end of shell initialization matters because precedence matters. The last activator wins, which means the environment ends in the state the repo expects rather than the state some other installer happened to leave behind.

This repo hardens the personal supply chain

The strongest security story here is not one big feature. It is the accumulation of small controls: GPG fingerprint pinning, SHA sidecars, attestation verification, quarantined release policy, and careful package-manager choices that avoid orphan binaries. Together they shrink the surface area where a dotfiles repo can be surprised.

The workshop. dotfiles — the home base: distributes agent instructions hub-and-spoke across coding agents, ships vendored local emulator and telemetry stacks, and tests itself in a throwaway devcontainer sandbox

hironow, Creator/Maintainer · hironow (hironow) · GitHub

That quote is the clearest summary of the repo's posture. It is not just configuring a shell. It is protecting a workflow that installs a lot of executable tooling, then asks both humans and agents to trust it.

Why this is not just chezmoi, Nix, or a fancy shell setup

Project	What it optimizes for	Where it differs
Traditional dotfiles	Convenience and personalization	Usually assumes one operator and one host
chezmoi	Templating and secret management	Less opinionated about agent identity and workspace parity
Nix/home-manager	Declarative reproducibility	Powerful, but steeper and more language-specific
hironow/dotfiles	Agent-aware parity across surfaces	Treats identity, trust, and environment as one system

The contrast is not about winners and losers. It is about axis of optimization. This repo is narrower than Nix in some ways and broader than a shell setup in others, because it is solving for a specific reality: a single operator moving between host, container, and cloud while AI tools are part of the workflow.

That makes it feel closer to personal platform engineering than configuration management. The repo encodes policy, not just preferences.

The larger pattern: platform engineering for one

Seen as a whole, hironow/dotfiles is a personal platform layer. It binds identity, toolchain, and trust into one operating surface so the same work can happen on a MacBook, in a dev container, or in a remote workspace without re-learning the environment each time.

That is the useful pattern here. If you expect to work with both AI tools and multiple execution surfaces, the interesting question is no longer how to customize a shell. It is how to make the shell enforce the rules of your workflow.