# Cobalt Cockpit 0.6.0: From a Claude Code HUD to Mission Control

```yaml
url: "https://forg.to/articles/cobalt-cockpit-060-from-a-claude-code-hud-to-mission-control"
title: "Cobalt Cockpit 0.6.0: From a Claude Code HUD to Mission Control"
excerpt: "Eight development iterations, a rebuilt alert system, better agent orchestration, and a completely redesigned cyberpunk GitHub experience. When I first wrote about Cobalt Cockpit, the project was approaching v0.5.2. The idea was straightforward: I wa…"
author: "Cobalt"
author_url: "https://forg.to/@cobalt"
published: 2026-10-18
updated: 2026-10-18
read_time_minutes: 9
cover_image: "https://res.cloudinary.com/dxkpmcrel/image/upload/v1792316596/forg/articles/thhzejtncn0fadybf3cu.png"
```

## TL;DR

Eight development iterations, a rebuilt alert system, better agent orchestration, and a completely redesigned cyberpunk GitHub experience. When I first wrote about Cobalt Cockpit, the project was approaching v0.5.2. The idea was straightforward: I wa…

## Content

*Eight development iterations, a rebuilt alert system, better agent orchestration, and a completely redesigned cyberpunk GitHub experience.*

When I first wrote about Cobalt Cockpit, the project was approaching v0.5.2.

The idea was straightforward: I wanted more visibility and control over what Claude Code was doing while working on real software projects.

Not just a progress bar. I wanted to know which agents were working, what they were responsible for, why tasks were blocked, what had actually been verified, and whether Claude's claims of completion matched the available evidence.

At the time, Cockpit already had its HUD, Neural Flow, model telemetry, verification guards and Run Ledger.

Since then, I've pushed the project through eight more development iterations.

**Cobalt Cockpit is now at v0.6.0, and the project has grown into something substantially more useful.**

Here's what changed.

## **1. Better security and stronger verification**

The first major improvement after v0.5.2 wasn't a flashy new interface.

It was tightening the security model.

v0.5.3 focused on authorization, task identity and verification integrity.

The distinction matters because not every action originating inside an AI coding environment should have the same authority as a command typed by the actual operator.

Sensitive Cockpit operations now require an authorized human origin. Project fingerprints account for repository identity, review consultations require the expected agent identity, and verification holds are harder to bypass through corrupted or stale state.

The principle is simple:

**A coding agent reporting success is not the same thing as the system having evidence of success.**

That principle now runs through much of Cockpit.

## **2. Cobalt Guard became a proper alert system**

One of the biggest additions between v0.5.4 and v0.5.9 was the evolution of Cobalt Guard.

Originally, Guard could notify me when a run needed human attention.

But a single notification isn't particularly useful if I'm away from my desk.

So I started building around that problem.

Persistent alerts

v0.5.4 introduced optional reminders for unresolved conditions, with cooldowns, session budgets and acknowledgment controls.

An alert could repeat while the condition remained open, but it wouldn't repeat forever.

Acknowledging an incident stopped its reminders without pretending the underlying problem had been fixed.

Verified notification transport

v0.5.5 introduced something I consider particularly important: testing the notification channel itself.

Cockpit distinguishes between a notification being attempted, the host reporting that it was sent, and a person confirming that they actually observed the test.

I tested this on my own setup: Claude Code running remotely inside a Boat development environment, connected over SSH to Fedora KDE through WezTerm.

Initially, terminal bells worked.

Then I switched to the iTerm2-compatible notification channel and received readable desktop notifications, including the confirmation code.

I entered that code back into Cockpit, and it recorded my confirmation.

That was a satisfying milestone because the feature wasn't just passing mocked tests. I could actually see and hear it working across the remote connection.

Priorities and quiet hours

v0.5.6 added alert severity, configurable notification categories, persistent HUD warnings and timezone-aware quiet hours.

Normal blocked-task notifications can now be deferred while critical security conditions receive different treatment.

And because a terminal notification may itself trigger a bell, quiet hours needed to prevent notification calls rather than simply mute a separate sound effect.

I tested that behavior too, including a deferred notification arriving after the quiet-hours window ended.

## **3. An alert inbox that survives sessions**

A desktop notification disappears.

An engineering issue doesn't necessarily disappear with it.

v0.5.7 introduced /cockpit alerts, a persistent inbox with incident identities, priorities, timestamps, notification states and individual acknowledgments.

v0.5.8 improved how that information survives concurrent sessions.

Instead of relying only on shared history snapshots, acknowledgments gained their own durable storage keys. That prevents a stale session from overwriting another session's acknowledgment under the tested host-storage behavior.

I also added a return digest so Cockpit can summarize outstanding recorded alerts when I return to a project.

Then v0.5.9 introduced **record-only mode**.

This is useful when I want observability without interruptions.

Cockpit can record blocked runs, security failures and other alert-worthy conditions without sending desktop notifications or playing sounds.

It also added a *Since Last Look* summary, tracking new occurrences by identity rather than relying on timestamps.

The notification history is bounded, project-scoped and designed to avoid storing arbitrary prompts or source-code contents.

There are still limitations to cross-session visibility and storage concurrency, and those are documented rather than hidden.

## **4. v0.6.0 brings the focus back to Mission Control**

After several releases strengthening Cobalt Guard, I wanted the next milestone to improve Cockpit's original purpose: understanding and coordinating agent-driven development.

That's what v0.6.0 delivers.

Agent Inspector

The new /cockpit agents command provides a detailed view of the swarm.

I can inspect assigned tasks, agent tiers, ownership, dependencies, orchestration waves, capacity, last observed activity and verification status.

There's also a task-specific view:

/cockpit agents <task-id>

One detail I care about is reasoning effort.

Cockpit distinguishes between effort requested for an agent, effort set at launch, effort applied by the host when observable, and effort the engine actually reports.

If the information isn't available, it says so.

It doesn't invent measurements.

Blocker Intelligence

The inspector also explains why an assignment isn't progressing.

Maybe another task must finish first. Maybe two agents want to write to overlapping files. Maybe the agent pool has reached its capacity. Maybe an escalation is waiting for the commander.

Cockpit uses its existing admission rules to explain these states, rather than inventing a separate scheduling system.

The explanations are informational. They don't automatically override ownership or clear blocked work.

Verification Readiness

The other new command I'm particularly pleased with is:

/cockpit ready

It shows what's preventing a task from being declared DONE.

That can include incomplete milestones, failed or stale verification gates, unresolved Stop Guard holds, pending reviews or missing acceptance evidence.

Cockpit distinguishes checks observed through command results from results merely reported by an agent.

The command doesn't approve anything. It explains the existing completion rules.

This is the direction I want the project to keep moving in: **less guessing about progress, more clarity about the actual state of the work.**

## **5. Opus, Sonnet and Haiku working together**

Cobalt Cockpit supports two orchestration profiles.

In OPUS_LED, Opus acts as the main coordinator, while Sonnet handles bounded engineering and reviews, and Haiku handles lightweight scouting and utility tasks.

In SONNET_LED, Sonnet leads everyday development, while Opus is available for admitted architecture and review consultations.

The main session's reasoning effort remains under the operator's control. Subagent effort can be selected based on the task.

Cockpit manages assignment records, resource budgets, dependencies and ownership rules.

It doesn't promise that every available agent will be used, and it doesn't replace Claude Code's underlying model availability or permission controls.

For my more demanding engineering sessions, I currently prefer Opus as coordinator, Sonnet for implementation and Haiku for bounded reconnaissance.

The aim is effective delegation, not creating a swarm just to watch agents move around.

## **6. A complete cyberpunk README redesign**

The other big update isn't a runtime feature at all.

**I completely redesigned the Cobalt Cockpit GitHub README.**

The old README contained plenty of technical information, but visually it looked much like any other developer repository.

I wanted the landing page to reflect what Cockpit actually feels like.

The new design includes a custom cyberpunk Mission Control banner, cobalt-blue visuals, light and dark variants, animated SVG elements, an illustrated module gallery and expandable documentation sections.

There's also a 44-second animated walkthrough showing the Cockpit interface and its workflow.

The demo uses scripted inputs against the real plugin's rendering and command interfaces in an offline test host. It's explicitly labeled as a synthetic demonstration, not footage of an autonomous production run.

The documentation has also been reorganized into dedicated guides, making the README easier to explore without discarding the detailed architecture, security and configuration information.

And everything is designed around GitHub's actual Markdown capabilities.

No fake web-app controls embedded into a README.

You can see the new look here:

**https://github.com/echelong/cobalt-cockpit**

## **7. What about testing?**

For the v0.6.0 engineering milestone, the verification report recorded:

**2,161 passing tests across 55 files, with zero failures.**

The release also passed its local TypeScript, strict plugin validation, archive checks, public audit and secret-scanning gates.

GitHub CI and the Gitleaks workflow passed on the v0.6.0 implementation commit.

A new acceptance harness also ran two actual Claude Code host processes against disposable storage, completing ten checks without using model calls, credentials or the operator's real data.

Separate independent reviews examined the new features, security-sensitive changes and Directory compatibility refactor.

Some newer runtime behavior still needs human acceptance in live sessions. I'm keeping those results separate from automated verification.

That's intentional.

Passing tests matters, but I don't want a testing summary to imply that every possible runtime condition has been observed.

## **8. The Anthropic Plugin Directory**

Cobalt Cockpit has also been submitted to the Anthropic Plugin Directory.

The Directory's validator previously flagged a capability-inspection issue involving how certain host API calls were structured.

v0.6.0 includes a refactor addressing that class of finding, along with expanded documentation of the plugin's capabilities and a local regression check.

**Directory approval is not yet confirmed.**

The repository remains publicly available on GitHub independently of that review.

## **What's next?**

Cobalt Cockpit started as a way to see what Claude Code was doing.

It's gradually becoming a way to understand why work is progressing, why it's waiting, which agents are involved, and what evidence supports a completion claim.

There's still plenty to improve, especially around agent ergonomics, coordination, resource usage and making the HUD more actionable during complex development sessions.

But v0.6.0 feels like an important step.

I'm building this because I use AI coding agents on real projects, and I want the surrounding tooling to make them easier to supervise, not harder to understand.

If you're using Claude Code and care about observability, bounded delegation and verification, take a look.

**Cobalt Cockpit is open source under MIT.**

Repository and redesigned README:

https://github.com/echelong/cobalt-cockpit

I'm interested in feedback from other developers using multiple agents, particularly around what you wish you could see during a long-running coding session.

## Links

- Article: https://forg.to/articles/cobalt-cockpit-060-from-a-claude-code-hud-to-mission-control
- Author: https://forg.to/@cobalt
- Forg: https://forg.to

---
Published on [Forg](https://forg.to), a social network for people who create and ship on the internet.
_HTML version: https://forg.to/articles/cobalt-cockpit-060-from-a-claude-code-hud-to-mission-control_