ConfigLens v0.1.0-beta.3 — Public Beta

ConfigLens explains where a Claude Code or OpenCode configuration value actually comes from.

Point it at a project and it traces each configuration source, the precedence between them, which
values are overridden, and which observed value wins — without guessing and without inventing
certainty.

What it does

• Resolves configuration for Claude Code and OpenCode across user, project, directory, managed
  and inline sources.
• Reports the observed winner for each key, the entries it displaced, and the precedence rule that
  decided it.
• States its own coverage gaps explicitly. When a source is blocked, unreadable or unverified it
  says so, rather than presenting an observed value as the effective one.
• Runs offline and read-only. It reads configuration files and prints a report; it makes no network
  request and spawns no process — a property enforced by a test in the source tree.
• Redacts credentials on every output channel. A share-mode report masks detectable secrets and
  machine-specific paths, and each report states its remaining privacy limitations, so a redacted
  report is not mistaken for an anonymous one.

Supported platforms

Platform	Archive
Windows (x86-64)	configlens-v0.1.0-beta.3-x86_64-pc-windows-msvc.zip
Linux (x86-64, glibc)	configlens-v0.1.0-beta.3-x86_64-unknown-linux-gnu.tar.gz
macOS (Apple Silicon)	configlens-v0.1.0-beta.3-aarch64-apple-darwin.tar.gz

Those are the only three builds published: there is no macOS Intel and no Linux ARM64 archive.

Verify what you downloaded

Every archive is checksummed, and each one is accompanied by a CycloneDX 1.5 SBOM
(configlens-<tag>-<target>.cdx.json) generated from the pinned dependency graph. The SBOM is a
dependency inventory, not a signature.

• macOS / Linux: sha256sum -c SHA256SUMS
• Windows: certutil -hashfile <file> SHA256 and compare with SHA256SUMS
• SBOM: any CycloneDX viewer, or read it as JSON

The published binaries are unsigned and unnotarized. Your operating system may warn on first run;
verifying the checksum above is the mitigation.

Install

See the README for archive extraction, checksum
verification and build-from-source instructions.

Status: beta, and honest about it

This is beta software, published as an open-source public beta. Two adapters ship today, both at most
fixture_verified: their precedence rules have been checked against this project's fixtures and the
pinned upstream source, not against a live upstream client run. The evidence ladder is
inventory_only < documented < fixture_verified < upstream_conformance_verified, and no adapter
currently claims the top rung. Some documented behaviours are unverified, and every report says which
ones.

What changed in this beta is recorded in the
CHANGELOG.

There is no automatic update or installation mechanism, and nothing in this release contacts the
network.

ConfigLens v0.1.0-beta.2 — Beta

This beta is superseded. The latest available beta is
ConfigLens v0.1.0-beta.3 — Public Beta.
Use that unless you specifically need this build for historical reference or testing.

ConfigLens explains where a Claude Code or OpenCode configuration value actually comes from. Point it
at a project and it traces each configuration source, the precedence between them, which values are
overridden, and which observed value wins — offline and read-only, without inventing certainty.

What changed in this release

Published 2026-10-11 (commit 51a2ca7). Behaviour changed for one input class, and new checks arrived.

Added

• Dependency policy — deny.toml plus a CI job that fails on a RustSec advisory, a yanked
  release, a licence outside the four present in the graph, a wildcard or git dependency, or a
  registry other than crates.io.
• Fuzz targets — three cargo-fuzz targets (parse_documents, resolve_precedence,
  hostile_inputs) with a committed, coverage-minimised seed corpus, a bounded CI smoke job, and a
  longer weekly scheduled pass.
• SBOM — a reproducible, validated CycloneDX 1.5 document per release target, attached to the
  release. SBOM assets begin with this release; beta.1 has none.
• Recorded demo — one real asciinema recording of precedence resolution across three layers.

Fixed

• Security: terminal control characters in report pointers. A configuration file could put an ESC
  sequence (or a bidi or zero-width character) in an object key name, and the local JSON report
  printed it verbatim as part of the resolution pointer, so the report could repaint the terminal of
  whoever read it. Pointers are now sanitised at every rendering boundary, with regression coverage
  across scan, explain, doctor, snapshot and diff in both path modes.
• OpenCode $OPENCODE_CONFIG_DIR was read as a file. Upstream treats the value as a directory
  and loads opencode.json / opencode.jsonc from inside it. The previous build refused a directory
  value with not_a_regular_file and accepted a file value as a source — the opposite of upstream in
  both cases. The layer now reads the two files inside the directory (.jsonc overriding .json),
  at a source-verified precedence rank, so the former placement-coverage gap is gone.
• OpenCode project configuration read only one file — a possible wrong winner. A working directory
  nested below the repository root could be resolved from the wrong (ancestor) file, and every
  intermediate ancestor was dropped. Discovery now walks from the working directory up to the
  boundary, merging every level outermost-first, so the nearest file wins and every ancestor
  contributes.

Verified (no code change) — the declared minimum supported Rust version
(rust-version = "1.85") is genuinely verified: cargo +1.85.0 check --locked --all-targets --all-features exits 0.

Not yet present in this release: the --quiet flag and the unified prerelease version
identification, both of which arrived in beta.3.

Supported platforms

Platform	Archive
Windows (x86-64)	configlens-v0.1.0-beta.2-x86_64-pc-windows-msvc.zip
Linux (x86-64, glibc)	configlens-v0.1.0-beta.2-x86_64-unknown-linux-gnu.tar.gz
macOS (Apple Silicon)	configlens-v0.1.0-beta.2-aarch64-apple-darwin.tar.gz

Those are the only three builds. There is no macOS Intel and no Linux ARM64 archive.

Each archive is accompanied by a CycloneDX 1.5 SBOM (configlens-<tag>-<target>.cdx.json) generated
from the pinned dependency graph. The SBOM is a dependency inventory, not a signature.

Verify what you downloaded

• macOS / Linux: sha256sum -c SHA256SUMS
• Windows: certutil -hashfile <file> SHA256 and compare with SHA256SUMS
• SBOM: any CycloneDX viewer, or read it as JSON

The published binaries are unsigned and unnotarized, so your operating system may warn on first
run; verifying the checksum is the mitigation.

Install

See the README for archive extraction, checksum
verification and build-from-source instructions.

Limitations

Two adapters ship, both at most fixture_verified: their rules were checked against this project's
fixtures and the pinned upstream source, not against a live upstream client run, so this is not a
claim of complete upstream compatibility. Some documented behaviours are unverified and each report
says which. There is no automatic update or installation mechanism, and nothing here contacts the
network.

Earlier and later betas remain available for historical reference and testing.

ConfigLens v0.1.0-beta.1 — Early Beta

This is an early beta, superseded. The latest available beta is
ConfigLens v0.1.0-beta.3 — Public Beta.
Use that unless you specifically need this build for historical reference or testing.

ConfigLens explains where a Claude Code or OpenCode configuration value actually comes from. Point it
at a project and it traces each configuration source, the precedence between them, which values are
overridden, and which observed value wins — offline and read-only, without inventing certainty.

What shipped in this release

The first published ConfigLens beta (published 2026-10-11, commit 35ad132). It contains the core
CLI — clients, scan, explain, doctor, snapshot, diff and schema, with the documented
exit-code model, a bounded OpenCode adapter and a bounded Claude Code adapter, and text and JSON
report renderers.

Known issues in this release, fixed in later betas

These are real defects of this build, recorded here for accuracy. They are not present in
beta.2 or beta.3, which fixed them:

• $OPENCODE_CONFIG_DIR was read as a file. Upstream treats the value as a directory and loads
  opencode.json / opencode.jsonc from inside it. This build refused a directory value with
  not_a_regular_file and accepted a file value as a source — the opposite of upstream in both
  cases. Corrected in beta.2.
• Project configuration was read from a single file — a possible wrong winner. Discovery used the
  working directory (or --project-root) as a search start and read only the first directory
  containing a project configuration file, so a working directory nested below the repository root
  could be resolved from the wrong (ancestor) file, silently. Corrected in beta.2, which now walks up
  to the boundary and merges every ancestor so the nearest file wins.
• Terminal control characters could reach the report. A configuration file could put an ESC
  sequence in an object key name, and the local JSON report printed it verbatim in the resolution
  pointer. Sanitised at every rendering boundary in beta.2.
• No dependency-policy, fuzz or SBOM tooling yet, and the declared MSRV was not yet independently
  verified. All three arrived in beta.2.

Supported platforms

Platform	Archive
Windows (x86-64)	configlens-v0.1.0-beta.1-x86_64-pc-windows-msvc.zip
Linux (x86-64, glibc)	configlens-v0.1.0-beta.1-x86_64-unknown-linux-gnu.tar.gz
macOS (Apple Silicon)	configlens-v0.1.0-beta.1-aarch64-apple-darwin.tar.gz

Those are the only three builds. There is no macOS Intel and no Linux ARM64 archive.

This release predates CycloneDX SBOM assets. It carries its three archives and SHA256SUMS only,
with no .cdx.json files — SBOM generation and attachment began with beta.2. Do not expect a
configlens-v0.1.0-beta.1-<target>.cdx.json here.

Verify what you downloaded

• macOS / Linux: sha256sum -c SHA256SUMS
• Windows: certutil -hashfile <file> SHA256 and compare with SHA256SUMS

The published binaries are unsigned and unnotarized, so your operating system may warn on first
run; verifying the checksum is the mitigation.

Install

See the README for archive extraction, checksum
verification and build-from-source instructions.

Limitations

Two adapters ship, both at most fixture_verified: their rules were checked against this project's
fixtures and the pinned upstream source, not against a live upstream client run, so this is not a
claim of complete upstream compatibility. Some documented behaviours are unverified and each report
says which. There is no automatic update or installation mechanism, and nothing here contacts the
network.

Earlier and later betas remain available for historical reference and testing.