WorkLouderCTL uses evidence-based compatibility claims. A version is listed as supported only after fixtures, automated checks, device readback, and rollback verification cover the relevant operations.
v0.1.0 is the first signed/notarized public release. v0.1.1 keeps that
distribution boundary and adds RPC-health-gated provider leases, Codex
26.730.61309, independent microphone keys, and a persistent Codex AppSense
relay. The versions below are exact verified adapters rather than a
promise that an unlisted future app build will be writable.
The canonical release-gated form is
spec/compatibility-matrix-v1.json.
worklouderctl compatibility list|show|verify exposes the same embedded data to
humans and agents. ./scripts/verify-compatibility-matrix.sh requires exactly
one matrix record for the version declared by Cargo.toml; CI therefore blocks
every future version bump until its application, bridge, firmware, evidence,
claim-boundary, and required-gate inventory is added.
| Component | Research baseline | Current claim |
|---|---|---|
| Device | Work Louder Codex Micro | Initial target |
| Host OS | macOS | Initial target |
| Codex app | 26.730.61309 | Exact-release overlay for settings, six Agent Keys, eight logical Command Key slots, provider lifecycle, and persistent AppSense focus forwarding |
| Codex Companion Bridge | Protocol v1 | Fixture conformance plus exact-release overlay, persistent authenticated focus client, and current-schema transaction coverage |
| Work Louder Input | 0.17.3 | Deterministic sanitized structural fixture; original installed bundle was superseded |
| Work Louder Input | 0.18.0 | Exact-release overlay live-validated for device configuration, host settings, live reads, and bidirectional provider handoff |
| Input Companion Bridge | Protocol v1 | Fixture conformance plus every capability negotiated by the released Input overlay live-validated |
| Companion integration bundle | 0.1.1 | Deterministic exact-inventory tgz, installed exports, and conformance executable verified; attached by the tagged release workflow |
| Codex Micro firmware | v0.6.0 | Live status/files/export read boundary verified |
| Codex Micro firmware | v0.6.1 | Input-authoritative configuration and AppSense switching boundary; firmware programming remains Input-owned |
| USB | Observed | Provider writes, exact readback, reconnect portability, rollback, and final single-owner recovery verified |
| Bluetooth | Observed | Live read boundary verified; configuration mutation uses the same external provider gate |
The 2026-08-02 audit recorded Input updating from 0.17.3 to 0.18.0 during a live session. Adapter selection therefore re-reads the installed and running version immediately before planning and immediately before writing.
The public fixtures/ tree is regenerated byte-for-byte by
scripts/build-sanitized-fixtures.py. Its manifests recompute every size and
SHA-256, both Input snapshots pass structural and semantic CLI parsing, and a
sensitive-pattern scan gates the checked-in files. The fixtures are synthetic
minimum schemas rather than copies of observed user configuration.
For Codex 26.730.61309, codex-config-toml-read-v1 freezes the five Codex Micro
settings plus the new ACT10, ACT11, MIC1, and
separateMicrophoneKeys layout fields. The earlier 26.727.51351 audit supplied
the original live read-only evidence:
the five explicit Codex Micro settings validated, inherited layout defaults
were reconstructed, an atomic typed snapshot was reopened, and the source
config.toml SHA-256 was identical before and after. Static inspection found
the internal settings-read,
settings-write, get-global-state, and set-global-state handlers, while the
released build did not expose an external listener.
The separate runtime-health boundary is now hash-pinned to 26.730.61309. The
earlier captured
WRITE_FAILED transition left the device enumerated and settings intact while
the service retained stale connection/topology Promises and lost both
v.oai.hid and v.oai.rad subscriptions. A service-only restart performed
while Input was paused restored connected, battery readback, both
subscriptions, and the Codex layer without restarting either window. The CLI
adapter verifies the app, app.asar, HID topology watcher, and Input Monitoring
permission module hashes before using the persistent runtime bridge; a changed
byte disables this contract until new evidence is frozen. Live 26.730.61309
recovery completed in the same process and three subsequent status reads were
healthy without reopening an inspector.
The Codex Companion Bridge v1 fixture has cross-language evidence for
authenticated capability negotiation; frozen-definition settings snapshots;
source-SHA plus canonical-settings CAS; immutable backup; complete explicit-set
apply; and exact explicit/effective readback. It also verifies all six Agent Key
slots, command/Skill/task/keycap/empty assignment types, a separate canonical
global-state revision, complete-object apply, idempotent replay, stale-CAS
rejection, explicit restore, and automatic rollback after corrupt readback. Its
E2E path proves recent -> custom -> recent, brightness 100 -> 37 -> 100,
auto-off 3-minutes -> 10-minutes -> 3-minutes, and voice mode
push-to-talk -> realtime -> push-to-talk; restores the exact Agent Key revision;
and recovers the exact baseline settings source SHA-256. The exact-release
installer materializes the same authenticated bridge in Codex and fails closed
unless the application version, bundle hashes, service shape, and requested
capabilities match. The separate device RPC path reuses Codex's connected
CodexMicroService, verifies unchanged service/API/comm identities, and never
opens a second HID session.
For Input 0.18.0 and Codex Micro firmware v0.6.0,
input-bundled-device-kit-read-v1 has live read-only evidence over HID: the CLI
read status, listed keymap.json and smart_actions.json, exported their exact
bytes, matched device SHA-1 and host SHA-256, reopened the typed manifest and
files, and atomically published the bundle. The tested session used the
Bluetooth-reported connection (isUsbConnection=false). Input was gracefully
quit and reopened for each read. Cached keymap.json and smart_actions.json
remained byte-identical. Input may rewrite its own input_storage.json startup
metadata (options.started and Loki meta.revision/meta.updated) after a
reopen; a recursive comparison found no semantic configuration difference.
This original read-only boundary did not cover device, cache, or database
mutation. The later exact-release overlay validation below adds a separate
mutation claim without broadening the historical audit.
On 2026-08-03, version- and hash-gated overlays were installed into the released
Codex 26.727.51351 and Input 0.18.0 providers without activating, restarting,
or navigating either GUI. Four independent authorities completed
compare-and-swap apply, exact readback, and exact restore: Codex settings, Codex
Agent Keys, Input device configuration, and Input host settings. Input snapshots
also remained portable across session-local device identifiers after reconnect.
Provider ownership was exercised in both directions. The final recovery left Codex as the only owner with USB, comm/API, HID, and joystick subscriptions present, stopped Input, and restored the official Input app bundle with strict deep signature verification. See the frozen live validation record.
On 2026-08-05, the device configuration path was corrected to keep Input as the
byte authority. Automatic and --owner codex commands take a serialized Input
lease, require a successful device.status RPC rather than trusting connection
counters, and restore Codex after success or failure. Codex acquisition likewise
requires connected comm/API, both HID subscriptions, and a bounded RPC probe.
This prevents detected and stale native handles from being reported as ready.
Multi-file changes use the firmware transaction primitive or stop before the
first write; idempotency keys remain bound to the exact operation/baseline/target
tuple. The AppSense LaunchAgent keeps one private
authenticated bridge connection, retries device timeouts on the same service,
and performs one serialized exact-release reinstall only for transport or
capability failure. doctor reports relay process state and functional health
separately. Relay focus and device configuration share serialized provider and
device-operation locks; bridge recovery occurs only after those locks are
released, so configuration and frontmost-app events cannot race or invert lock
order.
The released Input writer did not negotiate optional preset, reset,
firmware-update, or bootloader-recovery authorities. Those operations therefore
remain synthetic-provider claims and fail closed against Input 0.18.0. Input
later applied its own selected v0.6.1 firmware during official startup; that is
not a CLI flash claim.
Each version adapter will use one of four explicit states:
- supported — fixtures and required hardware behaviors are verified;
- read-only — inspection is verified; mutations remain gated;
- experimental — an opt-in adapter exists with a documented test boundary;
- unknown — fields are preserved and inspection is allowed, while mutations wait for an adapter.
Before a mutation, WorkLouderCTL will detect and record:
- device identity and transport;
- firmware version;
- Input application version;
- Codex application version for Tier 1 inspection;
- device-file schema version;
- device file list, sizes, and checksums;
- Input cache/database format adapter;
- every unknown field that must be preserved.
An Input or Codex update alone will not silently select the nearest adapter. Every invocation re-probes the installed version and exact frozen hashes; inspection can report an unknown build, while writes require an exact match or a newly verified compatibility range. This prevents an upstream update from quietly using stale offsets or internal service assumptions.
The Companion Bridge uses capability negotiation rather than assuming capabilities from an application version. The current live overlay is additionally gated by exact app and main-script hashes; a future upstream-native protocol v1 listener can place internal device-kit and GUI updates behind Input's stable bridge adapter. The current isolated cross-language fixture additionally verifies exact base64 snapshot bytes, device SHA-1, host SHA-256, an independently recomputed deterministic revision, and a live compare-and-swap preflight. This is bridge contract evidence rather than a released Input 0.18.0 capability claim. The fixture writer also verifies complete apply readback, idempotent replay without a second write, stale-CAS rejection, explicit restore, and automatic rollback after a corrupt readback. These are transaction-engine claims; they extend only as listed in the separate exact-release live integration boundary above. Optional unnegotiated authorities remain fixture-only.
worklouderctl doctor therefore reports application health, AppSense relay
health, and authenticated
configuration readiness separately. configurationReady requires both bridge
handshakes and the complete Codex/Input apply-and-restore capability sets.
Missing endpoints, handshake failures, or incomplete capability negotiation are
warnings; --strict promotes any such warning to a failing exit status. This
probe is read-only and does not focus, reopen, or mutate either GUI/runtime.
The isolated dual-provider E2E performs both authenticated protocol handshakes,
requires all eight Codex/Input apply-and-restore capabilities, obtains
configurationReady: true with strict exit 0, and verifies the provider
configuration bytes are unchanged by the probe.
New compatibility claims require:
- sanitized before/after fixtures;
- a deterministic parser/serializer round trip;
- semantic validation coverage;
- a no-op apply result with no byte changes;
- one intentional modification with exact device readback;
- a verified rollback to the original checksums;
- the tested boundary recorded in this document.
See the frozen 2026-08-02 audit for current hashes, state authorities, protocol observations, and claim limits.