Built-in profiles migrated to registry packs

[lukehinds]

This page explains a change in nono v0.43 that may affect commands you've been running. If your workflow stopped working after upgrading, this is probably why.

What changed

In v0.42 and earlier, a few profiles — claude-code, codex, and the matching agent integrations (Claude Code plugin wiring, Codex hooks) — were compiled directly into the nono binary. You could run nono run --profile claude-code -- claude on a fresh install with nothing else set up.

In v0.43 those built-in profiles are removed. The same content now ships as registry packs:

• always-further/claude provides the claude profile (formerly claude-code) plus the Claude Code plugin.
• always-further/codex provides the codex profile plus the Codex plugin.
• always-further/openclaw provides the openclaw profile plus the openclaw plugin.

The first time you run nono run --profile <name> -- ... for one of these names, nono notices the profile isn't installed locally and asks whether to fetch the pack from the registry:

  ⊕  Install always-further/claude?

     The `claude` profile is provided by this registry pack.

     Publisher    always-further GitHub organisation
     Provenance   Sigstore cryptographic supply chain (verified on pull)
     Installs     sandbox profile + Claude Code plugin (hooks, skill)

  Continue? [Y/n]

Accepting installs the pack. Subsequent runs are silent.

Why

Two practical reasons:

1. Agent integrations move faster than nono itself. Claude Code, Codex, and others ship breaking changes on their own schedules. When the integration logic was inside the nono binary, every one of those changes needed a nono patch release to keep up. Packs ship independently from the agent's own repo, so updates land without a CLI release.
2. The nono codebase doesn't carry per-agent knowledge anymore. The pack model lets nono stay focused on the sandbox primitive itself — the agent-specific code lives next to the agent.

That's the whole motivation. There's no behaviour change inside the sandbox.

How this might impact you

You upgrade and run a command that used to work

nono run --profile claude-code -- claude

You'll see the install prompt above. Press Y and the pack is fetched, verified, and installed. After that, the same command works on every subsequent run with no prompt.

--profile claude-code continues to work after install — the pack ships an alias from the legacy name to the canonical claude. You can also start using --profile claude going forward.

Your custom profile extends claude-code

If you have something like:

{
  "extends": "claude-code",
  "meta": { "name": "my-claude" },
  ...
}

nono run --profile my-claude -- ... will trigger the same install prompt for the inherited base, then resolve normally. Your custom profile doesn't need any changes — extends: "claude-code" keeps working through the alias.

You run in CI or any non-TTY environment

The prompt can't be answered, so nono prints a hint and exits cleanly:

  install required but no TTY available. Either:
    nono pull always-further/claude
  or re-run with NONO_AUTO_MIGRATE=1 to install non-interactively.

Two ways to fix the CI job:

• Add nono pull always-further/claude (and/or always-further/codex) as a setup step before nono run, or
• Set NONO_AUTO_MIGRATE=1 in the job environment so the install happens automatically on first use.

NONO_NO_MIGRATE=1 does the opposite — suppresses the prompt entirely and fails with Profile not found. Useful if you want CI to fail loudly when a pack is missing rather than auto-install.

You don't want the prompt and don't want to install the pack

You can write your own profile from scratch and skip the official pack:

mkdir -p ~/.config/nono/profiles
$EDITOR ~/.config/nono/profiles/my-claude.json
nono run --profile my-claude -- claude

Profiles in ~/.config/nono/profiles/ shadow registry packs of the same name and never trigger the prompt.

You need to pin to a specific version

nono pull always-further/claude@1.2.3

The version is recorded in ~/.config/nono/packages/lockfile.json and won't change until you re-pull.

You need to remove an installed pack

nono remove always-further/claude

The wiring directives that were applied at install time (symlinks, JSON entries in agent config files, etc.) are reversed. Your custom profiles in ~/.config/nono/profiles/ are not touched.

You're offline or the registry is unreachable

The migration prompt requires a registry round-trip to fetch the pack. If you're offline, the install fails. There's no offline fallback to a built-in copy any more — the built-ins really are gone.

If you regularly work offline, pull the packs once while online and they'll stay installed.

If something doesn't work

The change is large enough that we expect some scenarios we haven't covered. Please file an issue if you hit any of these:

• A command that worked on v0.43 fails on v0.44 in a way not covered above.
• The install prompt appears in a context where it shouldn't (e.g. a script that previously succeeded silently).
• A pack installs but the agent then fails to find its plugin / hooks / skills.
• The decline path leaves your environment in a confusing state.
• Wiring directives don't fully reverse on nono remove.

Issue template: https://github.com/always-further/nono/issues/new

Useful information to include:

• nono version (nono --version)
• The command you ran
• Full stderr output, including the prompt and any error
• nono list --installed output
• Contents of ~/.config/nono/packages/lockfile.json if relevant
• Whether the issue reproduces on a fresh nono pull --force

Reverting to v0.43

If the new flow is blocking work and you need to keep moving while we resolve an issue, downgrade:

cargo install nono --version 0.43.x --force

This is a temporary mitigation, not a long-term path — v0.43 is no longer the supported release. Please open an issue describing what's blocking you so we can fix it on main.