🚀 Codify v1.3.0 - Apply Templates Directly, Fewer Sudo Prompts & a Crash Fix

We're excited to announce Codify v1.3.0! This release makes it easier to get started with a config you don't have yet, cuts down on repeated password prompts during long applies, and fixes a crash that could take down the terminal UI mid-run. Here's what's new.

Apply Templates Directly

Until now, using a template meant copying its config into a codify.jsonc file first and then running apply on that file. In v1.3.0, codify plan and codify apply accept a template name or id directly:

codify apply <template-name>

Codify pulls the template from the public registry and runs it like any other config, plan first and then apply after you approve it. You don't need to log in or create a file first. Templates are treated as read-only, so Codify never writes changes back to them.

The argument to plan and apply now resolves in this order:

1. A document id loads that document from the Codify dashboard
2. A file loads that file
3. A directory loads the Codify file inside it, and prompts you to pick one if there are several
4. Anything else is looked up as a template name in the registry

With no argument at all, Codify keeps the existing behavior. It uses the Codify file in the current directory, or your default dashboard document if you're logged in and there isn't one.

Clearer errors when nothing is found

If Codify can't find a config, the error now tells you why and lists every way you can point it at one:

No Codify file, directory, or template found matching "my-setup"

Codify looks for files named *codify.jsonc, *codify.json, *codify.json5 or *codify.yaml.

Usage:
  codify apply                      Use the Codify file in the current directory
  codify apply ./path/to/file       Use a specific file or directory
  codify apply <template name>      Use a public template from the Codify registry
  codify apply <document id>        Use a document from the Codify dashboard (requires login)

Run codify init to generate a Codify file from your current machine.

As part of this work, we also fixed a bug where pointing Codify at a directory outside your current folder that held a single Codify file (for example codify apply ../dotfiles) could resolve the file against the wrong directory.

Sudo Asks Once Per Session

A lot of resources need root access, and on a fresh machine an apply can hit sudo many times. Previously, each of those requests could prompt you for your password again. In v1.3.0, the sudo prompt saves your password for the rest of the session by default:

Enter to confirm and save for this session · Tab to confirm without saving

• Enter confirms and saves the password, so later sudo requests in the same run won't prompt again.
• Tab confirms for this one command only, so you'll be asked again next time.

The password is checked before it's saved and is only held in memory for the current run. It is never written to disk.

If you'd rather approve every privileged command yourself, run in secure mode with --secure (or -s). Secure mode never saves the password and prompts you for each sudo request, the same as before.

Fixed: "Memory Access Out of Bounds" Crashes

Some users saw Codify crash with RuntimeError: memory access out of bounds partway through a run. The cause was in Ink, the library that renders Codify's terminal UI. When part of the UI was removed from the screen, Ink kept a reference to a layout node that had already been freed. Once that memory was reused, the next render read invalid memory and crashed.

The fix is already in Ink 8.0.0, and we've backported it into the version Codify uses, so this crash should no longer happen.

Try it out!

Upgrade to v1.3.0 today:

codify update

Or install it with npm:

npm install -g codify

Or download the latest version from our docs.

/bin/bash -c "$(curl -fsSL https://releases.codifycli.com/install.sh)"

As always, if you run into any issues or have feature requests, please open an issue on GitHub.

Cheers!