agent cli / blind-spot audit / 2026-07-07

The fork question dissolved mid-audit — verified firsthand, not just claimed.

The verdict "cmux is best to fork" was reached on thin, asymmetric evidence. But the audit surfaced something bigger: cmux's chrome is already config-themeable — a claim I made earlier this session ("would require editing compiled Swift") was wrong, and I re-verified it myself against the real source, not a subagent's word.

try this before anything else

Real, shipped keys in ~/.config/cmux/cmux.json — confirmed by reading SidebarAppearanceCatalogSection.swift and WorkspaceColorsCatalogSection.swift directly. No Swift editing required.

{ "sidebarAppearance": { "tintColor": "#0b0b0c", "cornerRadius": 8, "material": "sidebar", "blurOpacity": 1.0 }, "workspaceColors": { "selectionColor": "#5fb8ae" } }

Findings — severity ranked

cmux's chrome IS config-themeable — my earlier claim was wrongverified firsthand
I said cmux's native chrome "isn't config-themeable" and would need Swift edits. Re-cloned and read the real source: tintColorHex, lightModeTintColorHex/darkModeTintColorHex, tintOpacity, blurOpacity, cornerRadius, material, blendMode, preset, plus workspace selectionColorHex/customColors — all real, shipped, settable via config. This may make the entire fork question moot.
damage avoided: weeks forking a codebase that didn't need it  ·  confidence: confirmed, not estimated
chestertons-fenceunknown-unknownsfirsthand re-check
"cmux is best" was reached with asymmetric, confirmation-shaped verificationmethodology gap
cmux got a real clone-and-grep; Mux0/Supacode got two web searches and README snippets. The queries themselves never tried to disconfirm ("cmux UI criticism," "Mux0 screenshots") — a test that can't fail isn't a test. The "more stars = easier to fork" assumption may even be backwards — more stars often means more opinionated design already baked in, harder to strip.
damage: could've picked wrong fork base  ·  now: partly moot per Finding 1
premortemoutside-viewinversionfalsificationladder-of-inference+4 more (same evidence)
The actual complaint (visual design) was never compared between candidatesgap
No screenshots, no chrome-source read, for Mux0 or Supacode, on either side. The stars/activity comparison that was run couldn't have addressed the thing Jason was actually asking about.
status: moot for cmux now (Finding 1)  ·  still open if cmux's tokens don't satisfy
consider-the-oppositefalsificationcalibration
Right after being told "stop evaluating tools," the next move was another tool-evaluation writeupbehavior pattern
Answering the direct question was correct. Producing a 4-way comparison doc was the same shape of activity just named as the problem — likely pressure to resolve the rebuke fast, not genuine falsification-seeking.
note: this audit is ~10 more agent calls of evaluation — named explicitly in Residual, not exempted
steelmanbias-blind-spot
If a fork happens anyway, these are real, checked risksconditional
Sparkle auto-update polls manaflow's real appcast via an EdDSA key baked into Info.plist — an unmodified fork silently self-updates and overwrites local changes unless the feed keys are stripped. Repo is a multi-platform monorepo (ios/ web/ webviews/ workers/ daemon/), 922 Swift references to "Sidebar" alone. Toolchain: Xcode 16+, Zig, Rust, with active build fragility in CI. Notarization for multi-machine distribution needs a restricted WebAuthn entitlement Apple must grant.
relevance: only if Finding 1's tokens don't satisfy and a fork is still pursued
unknown-unknowns
cmux's native-AppKit choice and theming architecture were deliberate, and burned once alreadyfence, still standing
README: the author rejected Electron/Tauri specifically for performance before going native — that reason still applies to any rewrite. GitHub issue #3511: custom palette theming already caused white-on-white invisible text from appearance-state coupling; the real fix (merged) was architectural separation, not more custom painting.
caution: going past the shipped tokens reopens a bug class already fixed once
chestertons-fence
"Horrible" was never pinned to a concrete, testable criterionundefined target
No contrast complaint, no layout complaint — an unspecified reaction. Even with real config tokens now available, there's nothing concrete to tune toward yet.
next step: name 2-3 specific things wrong, testable against the real tint/corner-radius/material tokens
chestertons-fence
Corrected confidencecalibration
Pre-Finding-1: ~20-30% that a fork specifically was necessary or would land in reasonable time for a non-Swift solo dev. Post-Finding-1: revise sharply toward "some fix exists without forking" (~70-80%, untested), and revise "a fork was ever necessary" down further.
calibration

Residual

Finding 1 confirms the keys exist — not that using them looks "clean and modern" to Jason. Untested, and per Finding 7 the target isn't defined yet.
Mux0's and Supacode's own theming systems were never checked with equal rigor — if cmux's tokens don't satisfy, the "best base" comparison is still on asymmetric footing.
Maintainer stance on forks (license permits it; community reception unknown) — not checked.
Self-audit caveat: this audit graded its own evidence. Findings 2–4 converge from the same transcript facts across many frameworks — flagged as same-model repetition, not 9x independent corroboration. Finding 1 is the one item verified firsthand against real source, not relayed.
This audit is itself ~10 more evaluation-shaped agent calls, arriving right after Finding 4's warning about that exact pattern. Explicitly requested via /blind, not self-initiated — the material difference — but worth naming so it doesn't quietly become the next thing this critique is aimed at.