If you use chezmoi_modify_manager together with chezmoi, there is one annoying bootstrap problem:

• chezmoi_modify_manager is needed while chezmoi apply computes file contents
• but the usual .chezmoiscripts/run_before_* hooks run too late to install it for the first apply

I wanted a solution that was:

• automatic
• shell-based
• version-pinned
• rerun only when the installer script changes

This post shows the setup I ended up with.

The problem

At first glance, it seems natural to put an installer script into .chezmoiscripts, for example, as a run_onchange_before_* script.

That helps with normal lifecycle management, but it does not solve the initial bootstrap.

Why? Because chezmoi needs to compute the target state before it runs those scripts, and modify_ files participate in that computation. If those files use chezmoi_modify_manager, then the binary must already exist before chezmoi apply reaches the script phase.

So the core issue is:

chezmoi_modify_manager must be installed before chezmoi apply starts doing the work that depends on it.

The approach

The solution is to split the problem into two:

1. Put the installer in .chezmoiscripts as a run_onchange_before_* script, so the script is tracked by chezmoi and reruns when its contents change.
2. Wrap chezmoi with a small shell function that manually runs that installer script before delegating to the real chezmoi apply.

That gives us the best of both worlds:

• proper chezmoi-managed script in the source repo
• successful first bootstrap
• automatic reinstall when the installer changes, such as when bumping the pinned version

The installer script

I placed this file in:

~/.local/share/chezmoi/.chezmoiscripts/run_onchange_before_00-install-chezmoi-modify-manager.sh

The script is version-pinned, architecture-aware, and idempotent. It also keeps a tiny version stamp, so it can skip work when the correct version is already installed.

A few notes:

• VERSION is deliberately hardcoded for simplicity
• STAMP stores the installed version so the script can cheaply detect whether work is needed
• --doctor provides a sanity check after installation

If you later want to upgrade, just change the VERSION string in the script. Because the script is a run_onchange_* script, chezmoi will detect the change.

Manual bootstrapping

After running “chezmoi init <URL>” and before running “chezmoi apply” for the first time, you must remember to manually execute this script

Alternatively, you can use the “wrapper” solution detailed next.

The wrapper

Now for the missing bootstrap step: we need to ensure the installer runs before chezmoi apply.

I used a shell function in my ~/.bashrc (or ~/.zshrc).

Then reload your shell:

With this in place, running:

does the following:

1. finds the real chezmoi
2. checks whether the installer script exists in the source directory
3. runs the installer script first
4. only then runs the real chezmoi apply

That is exactly what we need.

Why this works

This setup works because it respects the real dependency order.

The dependency is not:

“Run a script sometime before applying files.”

The dependency is:

“Ensure chezmoi_modify_manager exists before chezmoi starts evaluating anything that depends on it.”

A normal run_before_* script is still part of chezmoi’s internal apply pipeline, which is already too late for the very first bootstrap.

The shell wrapper moves the install step out of the pipeline and places it before chezmoi apply begins.

Why keep the installer in .chezmoiscripts at all?

Because it still gives you useful chezmoi behavior:

• the installer lives in your dotfiles repo
• it is versioned like everything else
• changing the script content is part of your normal dotfiles workflow
• the run_onchange_* naming still reflects the script’s intended lifecycle

In other words, the wrapper solves the bootstrap timing problem, while .chezmoiscripts keeps the implementation under chezmoi ‘s control.

Optional: ensure ~/.local/bin is on your PATH

If your shell does not already include ~/.local/bin, add it:

Happy dotfiles! 🙂

When I bootstrap a new machine with chezmoi, I usually start by cloning my dotfiles repo from GitHub over HTTPS:

That works well for the very first setup, because my SSH keys are not installed yet.

After the first chezmoi apply, though, my SSH keys are finally in place, and I want the dotfiles repository itself to switch from HTTPS to SSH automatically.

This sounds simple, but there is a small gotcha.

The goal

I wanted chezmoi apply to do this at the end of the first run:

• detect that the repo remote is using HTTPS
• convert it to the SSH form
• update origin automatically

For example:

• from https://github.com/username/dotfiles.git
• to git@github.com:username/dotfiles.git

My first attempt

My first version used a run_once_after_... script that called chezmoi source-path to find the source repo:

But when I ran chezmoi apply, I got this:

Why this fails

The problem is that the script is being run by chezmoi apply.

So if the script itself runs another chezmoi command, the second process tries to acquire the same persistent state lock that the original chezmoi apply already holds.

In other words:

• chezmoi apply starts
• it runs your script
• your script runs chezmoi source-path
• the nested chezmoi process waits on the lock
• eventually it times out

The fix

The solution is to avoid calling chezmoi inside the script.

Instead, make the script a template and use {{ .chezmoi.sourceDir }} to inject the source directory path when chezmoi renders the script.

Here is the working version.

Working script

Create this file:

Contents:

Why this works

There are two important details here.

1. The script is a template

The .tmpl suffix tells chezmoi to render the file before executing it.

That means this line:

gets replaced with the actual source directory path ahead of time.

No extra chezmoi process is needed.

2. The script runs after “apply”, and only once

Because the file name starts with run_once_after_, chezmoi runs it after the apply phase, and only once per machine unless the script changes.

That makes it a good fit for first-boot setup tasks like this one.

A note about the working directory

One subtle point: chezmoi scripts do not run in the source repo by default.

So even though we know the source directory, we still need to explicitly run:

before calling git remote get-url or git remote set-url.

Resetting the script state

If you need to test the script again after it has already run successfully, you can clear chezmoi’s script state:

That lets run_once_ scripts execute again.

Final thoughts

This ended up being a neat example of a general chezmoi rule:

If a script is already running inside chezmoi apply, avoid launching chezmoi again from that script.

When you need chezmoi-specific information in a script, templating is often the better solution.

For my bootstrap flow, this gives me the best of both worlds:

1. clone over HTTPS when no SSH key exists yet
2. install SSH keys during the first apply
3. automatically switch the dotfiles repo to SSH at the end

Exactly what I wanted.

If you use a similar bootstrap flow, hopefully, this saves you from the persistent state lock timeout.