Aricode v0.5.2 — section planner, Ollama-default, and a kinder default-deny.

Aricode v0.5.2 is on the registry as of this morning. This is a small release — point-two-of-something — but two of its three pieces shipped after fairly serious rewrites, and the changelog is worth a longer note than usual.

For anyone new: Aricode is the studio's coding harness. A CLI that runs against local or remote models, with a planner that decomposes a request into sections, a small group of sub-agents that work on each section, and a careful command-execution policy that defaults to deny and asks before doing anything mutating.

If you're upgrading from 0.5.1, three things to know.

The section planner.

In 0.5.1 the planner was sequential: a master agent wrote a plan, then a single executor walked through it, calling tools step by step. This was clear, slow, and occasionally led the executor down a path the planner didn't intend.

In 0.5.2, the planner produces a small manifest — a tree of up to eight sections, each with its own brief, dependencies, and acceptance criteria — and then phase-grouped sub-agents work on them. Independent sections run in parallel. Dependent ones wait. The master agent reviews each section's artefact before stitching the next phase.

# A planned task, viewed from the CLI

▸ task: implement export summaries (4 sections)
  ├─ section/managers      independent · ready
  ├─ section/application   independent · ready
  ├─ section/api           depends on managers, application
  └─ section/tests         depends on api

▸ dispatching phase 1 — 2 sections in parallel

Internally, this is a new pair of types — SectionTask and SectionResult — plus a SectionManifest describing the whole tree. The planner is allowed to propose a Resector Proposal mid-task: a suggestion that the codebase's file layout could be reorganised before the work proceeds. You can accept, decline, or postpone the resect. By default it postpones.

The ceiling of eight sections is on purpose. We tried twelve and sixteen during the rewrite. Eight is the largest number we found where the master agent could still hold the whole tree in working context without losing track of the early dependencies.

Ollama is now the default.

If you ran aricode setup in 0.5.1, the first question was "OpenAI-compatible endpoint URL?" and the second was "API key?". The default flow expected a hosted endpoint.

In 0.5.2 the wizard asks, instead, "Local server (LM Studio, Ollama)?", detects Ollama on localhost:11434 if it's running, and configures itself against it. If you'd like to use a hosted endpoint, that's the second branch of the wizard, and your existing config is untouched.

This is a small change with a big effect on first-run experience. The phrase "free and off the grid by default" appears on the Aricode page on the website. We thought it would be polite to make that actually true on first launch.

A kinder default-deny.

The command policy is the part of Aricode we are most careful with. The rules haven't changed:

• Three tiers of command: read-only (always allowed), mutating (allowed in your project after approval), privileged (opt-in, asked every time).
• Some commands are blocked forever — never executed, no escape hatch, full stop. The list: rm, sudo, bash, sh, chmod, kill, dd, nc.
• The environment passed to any executed command is sanitised: anything matching *_TOKEN, *_SECRET, *_KEY, AWS_*, OPENAI_*, or SSH_* is stripped before the command runs.
• If you really need to run something unusual, the user-only /shell <cmd> command lets you. The model cannot invoke it. It is, deliberately, your hand on the keyboard.

What changed in 0.5.2 is the prompt. In 0.5.1 the approval UI was a hard stop with a yes/no. In 0.5.2 it's an inline three-way selector, with the proposed command in the centre, and three options:

▸ section/managers wants to run:
    pnpm test --filter @ari/managers

  ◐ allow once        ◑ always (this section)
                ✕ skip

The middle option is the new one. "Always allow, for this section only" means the agent doesn't have to ask again for the same command pattern inside the current section's run — but the moment the section ends, the permission expires. We found this dramatically reduced the number of approval prompts while keeping the surface area of trust small.

Other bits.

• The project-memory file moved from .ariadne/ARIADNE.md to .aricode/ARICODE.md. The migration is automatic on first 0.5.2 run; the old file is left in place, untouched, so you can diff if you like.
• Hook events gained session-start and session-end. Variables available inside hook commands: ${file}, ${command}, ${cwd}.
• The /labs mode now hosts a few experimental commands — /hypothesis, /spec, /measurement, /dashboard — that we're not ready to commit to yet. They might disappear in 0.6.
• The Node SDK (createAricode({...}).createSession().run(input)) now yields a typed async iterator of structured events, instead of strings. Older string-mode is preserved behind a flag for one more release.

Getting it.

pnpm i -g aricode@0.5.2 if you've installed the CLI globally; aricode upgrade if you'd like the binary to handle it; brew upgrade aricode on the Mac. The downloadable Aricode.app on aricode.dev will pick this up on its next auto-update window.

0.6 is the next big one. It's a long story and will have its own note.

— A.