Claude MIDI Twister Shows Agent State

Claude MIDI Twister is Dylan Fisher's small hardware project that turns a DJ TechTools MIDI Fighter Twister controller into a live visualizer for Claude Code, Anthropic's coding agent. It deals with a very ordinary agent problem: once several coding sessions are running, the terminal stops being a good attention system. The takeaway is simple: agent state deserves a separate surface when the work becomes parallel, and Codex CLI users can steal the pattern without buying the same controller. For readers comparing the codex cli github path with hardware experiments like this, the useful question is not which tool is cooler; it is where your agent should ask for attention.

Claude MIDI Twister is a daemon that listens for Claude Code webhook events and updates the MIDI controller in response. Fisher said the idea came after seeing the Work Louder Codex Micro controller, then repurposing a MIDI Fighter Twister he already had under his monitor. When an agent needs attention, its control can flash red; clicking it can jump back to that session.

Watch the agent, not the chat log

The neat part of Claude MIDI Twister is not that it uses music hardware. The neat part is that it treats each agent session as something with state: idle, working, blocked, done, or waiting for a human.

That matters because agentic coding makes background work normal. One Claude Code session might be fixing a test. Another might be reading a bug report. A third might be paused on a permission decision. If the only signal is a terminal tab title, you will miss the moment where a useful assistant turns into a stuck assistant.

The trap is building a cockpit before you know what deserves a light. Start with the few states that change your behavior. Red for needs-human is useful. A rainbow mode for every log event is noise with knobs.

A Codex version of the same idea could be plain software. A tmux dashboard, a desktop notification, or a GitHub check can play the same role. We covered one nearby shape in Agent-Manager Gives Codex a tmux Dashboard, where the display is terminal-native instead of hardware-native.

The trick is a narrow event boundary

Fisher's project listens for Claude Code webhook events and turns them into MIDI updates. That is a good boundary. The coding agent does not need to know about knobs, LEDs, USB devices, or color rules; it emits events, and a small daemon translates them.

Codex users should notice the shape. OpenAI Codex CLI workflows often work best when the agent has clear repo instructions, a small set of allowed tools, and an external verification loop. The visualizer is just another subscriber to state, not the place where coding policy lives.

The trap is mixing control and display too early. A button that jumps to a session is helpful. A button that approves arbitrary edits is a much sharper object. If you add input, make the first actions reversible: focus session, open diff, rerun tests, copy branch name.

A small repo rule is enough to keep the boundary honest:

# AGENTS.md

## Agent session signals
- Treat external status displays as read-only unless this file names a specific action.
- Do not approve dependency changes, migrations, or deploy steps from a hardware control.
- Before marking work complete, run the verification command listed for the touched package.

That kind of instruction belongs near the code because local context beats a giant global memory file. It also gives your Codex agent something durable to follow when the fun prototype becomes part of daily work.

Translate the idea to a Codex CLI workflow

You do not need a MIDI Fighter Twister to learn from Claude MIDI Twister. The practical move is to define the state you wish your agent exposed, then route that state to the least distracting surface you already use.

For a codex cli github workflow, that surface might be a GitHub issue comment, a check run, or a local terminal panel. For more CLI patterns, keep an eye on the related training topic, especially if your work already revolves around AGENTS.md, branch diffs, and test receipts.

A minimal loop can look like this:

# Start an agent task in the repo.
codex 'Fix the failing auth redirect test. Keep the diff small.'

# Keep verification boring and explicit.
npm test -- auth-redirect

git diff --stat
git diff

The display layer should answer one question: what should I look at next? If the agent is still working, leave it alone. If tests failed, show yellow. If it needs a decision, show red. If it produced a clean diff with the requested verification, show green and make review easy.

The trap is treating visual state as proof. A green light is a pointer to a review, not a review. The actual receipt is still the diff, the test output, and any repository-specific rule the agent followed.

Try it when parallel work is real

Claude MIDI Twister makes the most sense when you run more than one agent session and lose track of them. If you usually run one prompt, wait, review, and commit, hardware state will likely be overkill.

It is also a better fit for local development than high-risk production control. A glowing controller under a monitor is great for attention. It should not become the place where schema migrations or deploy approvals happen.

Here is the useful fit check:

The opinionated version: hardware is charming, but the real product idea is externalized attention. Once you name that, you can implement it with LEDs, tmux panes, GitHub checks, or a tiny MCP bridge.

Try it safely checklist

Use this if you want to copy the Claude MIDI Twister idea for Codex or another local agent setup without turning your desk into an unsafe approval console.

• Pick only four states first: working, blocked, needs review, complete.
• Keep the first display read-only. Let controls focus a session or open a diff, not approve work.
• Add a repo-local AGENTS.md note that says what a complete task receipt requires.
• Write down the verification command before you start the agent.
• Prefer reversible actions for hardware buttons: focus window, rerun tests, open logs, copy branch.
• Keep secrets out of event payloads. Status events should not contain prompts, tokens, or private customer data.
• If you add MCP, make the first server read-only and scoped to status or issue metadata.
• Review one real failure. If the light was green but the diff was wrong, fix the state model before adding features.

A tiny MCP boundary note can be enough:

## MCP boundary
- Status display tools may read session state and repository metadata.
- Status display tools may not write code, approve diffs, push branches, or edit issues.
- Any write action must happen through the normal Codex CLI review path.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about codex cli github?

  Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “Claude MIDI Twister Shows Agent State.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• Claude MIDI Twister — source
• OpenAI Developers — AGENTS.md guide
• GitHub — openai/codex
• OpenAI developers: codex quickstart

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.