Coder Legion - Recent posts tagged codex

Meta-Architect for AI Coding Agents

Sun, 30 Aug 2026 03:18:23 +0000

AI coding agents can generate code quickly. The hard part is knowing whether the architecture makes sense, dependencies are real, logic holds, security was checked, and “done” is actually verified.

Meta-Architect is an open-source workflow governor for AI coding agents.

It adds a fail-closed release runway:

`Architecture → Evidence → Logic → Security → Experience → Build`
A build stays locked until the required upstream gates pass. Red stays red.

What it includes

6 gated lanes — $arch, $sage, $flow, $vet, $vibe, and $build
$maestro — a bounded manager that reads workflow state and choose the next safe action
11 public skills — including $align, $diagnose, $tdd, and $cleanup
Evidence grading — stack claims are marked VERIFIED, PARTIAL, or MISSING through GitMCP/MCP sources
Learning Loop — learnings begin as candidates and require source, evidence, authority, and a next verification path before promotion
Obsidian brain context — vault notes inform planning as vault_context; they do not become build evidence automatically
Ralph execution — approved plans become story-sized, verification-backed implementation loops
Security and release proof — MCP policy, redaction, dependency/exposure review, issue-linked evidence, checksums, SBOMs, and release summaries
55 supported AI-agent hosts through the Universal Plugin Broker compatibility model
Native Linux packages for Debian, Arch, and RPM, plus npm and Bash installation paths

Why it’s different

Most spec tools organize what an agent writes.

Meta-Architect governs what an agent can claim to have proven.

It separates discovery from evidence, context from authority, helper work from gate approval, and “looks finished” from verified build readiness.

🧩 Quick start

AI agent installation prompt

Copy and paste this prompt into your AI coding agent:

Install Meta-Architect for this project.

1. Detect the current AI host and its native project configuration surface.
2. Install or update `@jstn-sdk/ma@latest` using the host's supported package manager.
3. Set `MA_AGENT` to the detected host ID when a host-specific surface is available.
4. Run `ma setup` and accept the detected project scope and targets.
5. Verify the generated `.ma/` state and native host artifacts.
6. Report the installed version, selected host, generated files, and any unsupported capabilities.

Do not overwrite user-owned files, modify unrelated configuration, or claim a host is supported without verification.

Uninstall Meta-Architect: npm uninstall -g @jstn-sdk/ma
Uninstall Meta-Architect and Codex: npm uninstall -g @jstn-sdk/ma @openai/codex

Install into an AI vendor host

Install Meta-Architect once, then select the host surface before launch. The
pre-launch step detects installed hosts and writes the selected scope and
targets to .ma/prelaunch.json.

# Codex (reference host)
npm i -g @openai/codex@latest @jstn-sdk/ma@latest
ma --madmax --high

# Claude Code
MA_AGENT=claude-code npm i -g @jstn-sdk/ma@latest
MA_AGENT=claude-code ma --madmax --high

# Cursor
MA_AGENT=cursor npm i -g @jstn-sdk/ma@latest
MA_AGENT=cursor ma --madmax --high

# Any registered host surface
MA_AGENT=<host-id> npm i -g @jstn-sdk/ma@latest
MA_AGENT=<host-id> ma --madmax --high

I use AI coding agents daily.

Sun, 16 Aug 2026 13:37:07 +0000

My AI coding agent kept claiming "done" without proof. So I built gates for it.

I use AI coding agents daily. They're fast. They're also confident when wrong.

Last month mine recommended a library which doesn't exist. Another run claimed "build complete" with zero tests executed. Sound familiar?

So I built Meta-Architect. Open-source skill pack for Codex. Six fail-closed gates before anything ships:

$arch: architecture first, with a written decision record
$sage: every dependency claim graded VERIFIED, PARTIAL, or MISSING against upstream repos
$flow: logic and state review
$vet: security and dependency audit
$vibe: DX/UX review
$build: stays locked until all five pass

Red stays red. The agent stops instead of pretending.

What it won't do:

Replace your agent, runtime, or model
Run unattended
Claim "production-ready" without receipts

Current state: v0.1.13, Codex-only, MIT license. Claude Code and Cursor support on the roadmap.

github.com/JustineDevs/meta-architect

What's the worst thing your AI agent shipped while claiming success? Best answer becomes my first gate test case.

How to batch 5 coding-agent turns into 1 macro workflow

Tue, 21 Jul 2026 02:57:59 +0000

Disclosure: I maintain Tura.

Here is the simple idea. A normal coding agent may use five separate LLM turns for one predictable workflow.

Turn 1 — inspect

rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src

Turn 2 — apply the patch

- // old command handler logic
+ // patched command handler logic

Turn 3 — build

cargo build -p runtime

Turn 4 — test

cargo test -p runtime --lib

Turn 5 — lint

cargo clippy -p runtime --all-targets

The overhead is not only the shell commands. The model wakes up five times and receives the growing conversation again.

Tura exposes one macro tool called command_run, so the agent can send the same workflow once:

{
  "name": "command_run",
  "arguments": {
    "commands": [
      { "step": 1, "command_type": "shell_command", "command_line": "inspect files" },
      { "step": 2, "command_type": "apply_patch", "command_line": "apply patch" },
      { "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }
    ]
  }
}

Build, test, and lint still run. The model simply does not need a new turn between predictable steps.

In the full DeepSWE comparison, Balanced used 35.8% fewer turns and 31.1% fewer tokens than Codex CLI. Direct used 69.1% fewer turns and 77.5% fewer tokens.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

kasetto - declarative AI agent environment manager, written in Rust

Mon, 20 Apr 2026 21:09:16 +0000

Hey community!

I want to share an open-source tool I built for myself, and that I hope will be useful to other developers working with AI agents.

The Problem

The more AI coding tools we adopted, the messier our setup got. Skills and MCP servers installed manually, via individual commands, or copy-pasted from docs. Scattered across Claude Code, Cursor, Codex, Windsurf - with no way to version any of it, no way to share it with teammates, no way to reproduce it on a new machine or project.

Every new team member meant walking them through the same manual steps. Every new machine meant doing it all over again. And if someone changed a skill or added an MCP server, there was no way to propagate that to the rest of the team.

Sound familiar?

The Idea

I built kasetto to fix that. The idea is borrowed from things I already loved - the declarative reproducibility of dotfiles, the simplicity of uv for Python packages. What uv did for Python, kasetto aims to do for AI agent skills.

One YAML config describes your entire setup: skills, MCP servers, target agents. Commit it, share it, and everyone on the team gets the exact same environment. No manual editing, no drift between machines or teammates. New machine? One command.

The Name

Kasetto (カセット) is the Japanese word for cassette - as in a cassette tape. A cassette was a self-contained, portable thing: you recorded something once, handed it to someone, and it played back exactly the same on any device. No setup, no drift, no "works on my machine." That's exactly what kasetto does for your AI agent environment - package it once, share it, and it reproduces identically everywhere.

Why kasetto

Declarative - one YAML config, version it, share it, bootstrap a whole team in seconds
Multi-agent - 21 built-in presets: Claude Code, Cursor, Codex, Windsurf, Copilot, Gemini CLI, and more
Multi-source - pulls from GitHub, GitLab, Bitbucket, Codeberg including self-hosted and enterprise
MCP management - merges MCP servers into each agent's native settings file automatically
Global and project scopes - install skills globally or per-project, each with its own lockfile
CI-friendly - --dry-run to preview, --json for automation, non-zero exit on failure
Single binary - no runtime dependencies, written in Rust, fast cold starts

How It Works

Define your config:

agent:
  - claude-code
  - cursor
  - codex

skills:
  - source: https://github.com/org/skill-pack
    skills: "*"
  - source: https://github.com/org/skill-pack-2
    skills:
      - product-design
  - source: https://github.com/org/skill-pack-3
    skills:
      - name: jupyter-notebook
        path: skills/.curated

mcps:
  - source: https://github.com/org/mcp-pack

Then sync:

kst sync

That's it. Kasetto pulls the skills and MCP servers, installs them into the right agent directories, and merges MCP configs into each agent's native settings file. The next time you run sync, only what changed gets updated.

Command Overview

Kasetto ships with a focused set of commands - each does exactly one thing:

kst sync              # pull skills + MCP servers and install them
kst sync --dry-run    # preview what would change without touching anything
kst sync --json       # structured output for CI pipelines

kst list              # browse installed skills and MCPs interactively
kst list --json       # dump installed state as JSON

kst init              # scaffold a kasetto.yaml in the current directory
kst doctor            # check your environment and diagnose issues

kst clean             # remove all installed skills and MCP entries
kst self update       # update kasetto to the latest release
kst self uninstall    # remove kasetto and all its files
kst completions       # generate shell completions (bash, zsh, fish, etc.)

The binary is available as both kasetto and kst - the short alias makes daily use quick.

Install

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/pivoshenko/kasetto/main/scripts/install.sh | sh

Homebrew
brew install pivoshenko/tap/kasetto

Cargo
cargo install kasetto

What's Next

The roadmap includes agents management and hooks management. If you have ideas or run into issues, open an issue - feedback from real users shapes the direction.

github.com/pivoshenko/kasetto

If kasetto saves you time, a GitHub star means a lot. And drop a comment below - I'd love to hear what your AI agent setup looks like today, and what pain points you're still hitting.

We Ported NanoClaw from Claude to Codex. The Hard Part Was Not the Runtime.

Sat, 11 Apr 2026 14:27:43 +0000

NanoClaw started as an agent harness that was not just compatible with Claude, but heavily shaped by Claude while working inside its own repo. Porting it to Codex meant rewriting both the runtime and the instruction substrate that had been teaching the old agent how to extend the app.

Most "AI app ports" are not really ports.

Usually they are some combination of:

swap the SDK
change the model name
leave the runtime assumptions alone
declare victory

This was not that.

When Anthropic tightened Claude subscription usage for third-party harnesses, one thing became obvious fast:

Building a serious agent system on top of a first-party subscription runtime is not a stable foundation.

That did not instantly kill NanoClaw. But it did force the right question:

What parts of this system are actually our architecture, and what parts are just the residue of the agent runtime that originally helped build it?

That turned out to be the whole story.

NanoClaw Was Built Inside an Agent World

NanoClaw originally evolved in a Claude-native operating model.

The workflow looked roughly like this:

point Claude Code at the repo
give it a stack of markdown instructions
run command-driven setup flows
let it scaffold, extend, and refine the app from inside that environment

That means the old system was not merely "compatible with Claude."

It was, in a very real sense, built by an agent that also helped define the repo's conventions for how future work should happen.

So once we decided to make NanoClaw truly Codex-native, the job was not:

"replace Anthropic with OpenAI."

The real job was:

separate the application from the worldview of the agent that originally co-authored its architecture.

The Markdown Was Part of the Runtime

This is the part that matters if you have ever let an agent spend serious time extending a codebase.

NanoClaw did not just have docs. It had a markdown-based behavioral layer:

CLAUDE.md
.claude/skills/...
setup flows
installer guidance
capability docs
hidden conventions for how the repo should be extended

These files were not just passive notes.

They told the agent:

how to initialize the app
how to install integrations
how memory should work
how channels should be extended
how "skills" should be applied

So some of the .md files were effectively architecture, even if they were not executable TypeScript.

That meant the port had two distinct layers:

Port the host/container runtime
Audit and rewrite the instruction layer that had been shaping the system

If we only did the first, the app would still think in Claude-shaped terms.

What NanoClaw Actually Is

At its core, NanoClaw is a small Node.js orchestrator for running isolated assistants inside containers.

The host process owns:

channels
routing
SQLite state
scheduling
group registration
IPC
container lifecycle

The container owns:

the actual agent runtime
group-local context
active skills
delegated subagents
tool access through MCP

That architecture survived the port.

What changed was the substrate it was built on.

What Was Actually Claude-Specific

Before the port, Claude-specific assumptions were everywhere:

Claude SDK query loop
CLAUDE.md instruction contract
.claude/ session and state layout
.claude/skills/ install model
old slash-command setup flows
Claude-era delegation semantics
remote control built around Claude tooling

And because the app had evolved with Claude actively working in the repo, those assumptions were reinforced both in code and in markdown.

So the first real task was not coding.

It was classification:

what is host application behavior?
what is Claude-specific runtime behavior?
what is a real feature that just happens to be wearing Claude-shaped names?
which markdown files are still runtime-significant?
which ones are just historical scaffolding now?

That step mattered more than any single code change.

If you classify the layers wrong, you either delete real capabilities or preserve the wrong abstractions.

The Port Was Not "Remove Claude, Add Codex"

A real port required four categories of work.

1. Replace the runtime contract

The old container runner was built around Claude-native execution.

The new one is built around Codex CLI running non-interactively inside the container.

That meant:

building prompt context from host state plus group instructions
invoking Codex correctly for fresh turns and resumed turns
streaming results back through a stable host/container protocol
preserving session continuity where possible

That sounds simple until you hit the reality that CLI surfaces diverge in annoying ways.

We hit bugs where:

flags worked on codex but not codex exec
fresh turns accepted options that codex exec resume rejected

Those are the kinds of portability problems that do not show up in architecture diagrams. They only show up when the host queue is already working and production message flow starts failing on resume paths.

2. Rewrite the instruction layer

This was the difference between a fake port and a real one.

The Claude-native repo had accumulated behavior through markdown:

skills
setup flow
integration guidance
memory conventions
extension patterns

We had to go file by file and make hard calls:

convert
replace
prune
delete

That meant moving from Claude-specific conventions to Codex-native ones:

CLAUDE.md became AGENTS.md
repo and group skills became SKILL.md based
old .claude/skills/ assumptions were removed
setup had to be rewritten around the runtime that actually exists today

This was not glamorous work, but it was essential.

If the repo still teaches the wrong mental model to the next agent that works in it, the architecture immediately starts drifting backwards.

3. Keep the real product features

One easy failure mode in a port is to treat every old feature as vendor-specific and quietly delete it.

That would have been wrong here.

Some things really were Claude-specific and needed to die:

Claude SDK integration
Claude remote control
old Claude-only marketplace conventions

But other things were just product capabilities that happened to live in a Claude-native system:

Telegram
WhatsApp
Web UI
subagent delegation
host skills

Those needed to be ported, not discarded.

The right question was not:

"Does this mention Claude?"

The right question was:

"Is this a real application capability, and does Codex have a legitimate equivalent or integration path?"

4. Make the host own the architecture

This is the actual lesson of the whole project.

The clean shape is:

NanoClaw owns orchestration
NanoClaw owns state
NanoClaw owns channels
NanoClaw owns setup
NanoClaw owns skills
Codex is the agent backend

If the host owns those things, the backend is replaceable.

If the backend owns those things, the host is just branding.

The Bugs That Proved the Point

The most interesting bugs in this kind of port are not random. They reveal exactly where your assumptions still belong to the old system.

Bug 1: The bot looked alive but was brain-dead

Telegram connected.
Messages were reaching the database.
Logs looked active.

But nothing was actually being processed.

Why?

Because WhatsApp was loading even when it was not really configured, entering a reconnect loop, and blocking the async startup path before the message loop was fully alive.

That produced a nasty half-working state:

inbound messages landed in SQLite
logs looked normal enough
the main message loop never really came online
the system looked alive while functionally dead

The fix was to stop treating channel startup as monolithic:

load channels only from real config/auth state
allow channel connection failure without killing overall startup
skip missing channels cleanly instead of blocking the process

That sounds basic. It was not basic in context. It was a symptom of a system that had grown around agent-era assumptions instead of explicit host orchestration.

Bug 2: Auth existed, but Codex still returned 401

This was my favorite bug in the whole port because it was pure systems work.

The host was logged into Codex.
The container was supposed to inherit auth.
But every in-container turn failed with:

401 Unauthorized: Missing bearer or basic authentication in header

The credentials were not absent.
They were misplaced.

The chain looked like this:

auth was copied into a nested .codex/.codex/auth.json
that path was mounted into the container
Codex expected auth relative to $HOME/.codex/auth.json
the file existed on disk, just not where the CLI actually looked

This is the kind of bug that disappears if you only talk in high-level diagrams.

It only becomes obvious when you trace:

host path
mounted path
container $HOME
actual CLI lookup conventions

The fix:

flatten the per-group Codex state layout
mount it directly to /home/node/.codex
migrate the old nested layout forward

After that, the 401 vanished and the live message path finally completed.

Bug 3: Resume was not the same as fresh execution

Fresh turns worked.
Resume did not.

The reason was simple and annoying:

codex exec resume did not accept the same options as the fresh execution path.

That is a perfect example of why "we already integrated the CLI" is not a meaningful milestone.

You have to test:

fresh turns
resumed turns
session restoration
output handling after resume

Those are separate runtime contracts, even when they share most of the binary name.

What the System Looks Like Now

The current NanoClaw branch is not "Claude code with Codex paint."

It is a different runtime model.

Today it has:

a Codex-native container runner
AGENTS.md for project and group instructions
SKILL.md based skills
per-group Codex state
Telegram, WhatsApp, and Web UI channels
Codex-backed delegation through MCP
host-owned setup and orchestration

Most importantly, it no longer depends on the repo being interpreted through Claude-native markdown conventions to keep evolving correctly.

That was the actual finish line.

Not "the build passes."

Not "the logs look healthy."

But:

the application can now be operated, extended, and reasoned about as a Codex-native system.

The Real Lesson

The strongest takeaway from this work is that agent-built systems can end up with architecture embedded in places most teams do not normally treat as architecture.

In this case, that included:

markdown instruction files
setup flows
skill directories
implied extension workflows
hidden filesystem conventions

If you want to port a system like that, you have to audit all of it.

Not just the code.

Not just the SDK.

All of it.

Because once an agent has spent enough time building inside a repo, the repo starts encoding assumptions about that agent's worldview.

That is fascinating when it works.

It is dangerous when you need to switch runtimes.

If You Are Thinking About Doing This Yourself

My advice is:

inventory the instruction layer before touching the runtime
treat markdown conventions as potentially runtime-significant architecture
separate host ownership from backend ownership early
verify real CLI behavior instead of trusting docs from memory
test startup, auth, fresh turns, resumed turns, and recovery independently
do not call it a port if you quietly deleted capabilities that had real equivalents

The hard part is not replacing the model.

The hard part is identifying all the places where the old model had already shaped the application.

Once you do that, the work becomes much clearer:

you are not porting an SDK. You are reclaiming the architecture.