Staging-ground chrome-devtools-mcp Nix flake for cross-project reuse

[srid]

A reusable Nix flake wrapping chrome-devtools-mcp, staged inside the
Kolu repo at examples/chrome-devtools-mcp-nix/ so the shape can be
iterated on before it's extracted to its own repo (e.g.
github:srid/chrome-devtools-mcp-nix). Consumers point their Claude
Code .mcp.json at nix run ...; the flake provides a pinned npx
invocation with nodejs in the closure.

The volatility boundary is the interesting part. The wrapper owns one
concern — launching chrome-devtools-mcp at a pinned version — and
nothing else. Chrome binary provisioning stays with the consumer
(--executable-path passes through via "$@"), because different
projects have different answers: Playwright's Chrome-for-Testing (like
Kolu does today), system Chrome, a container, a devshell-provided
binary. Bundling any one answer into a shared wrapper would leak a
project-specific choice into a cross-project interface. The README
calls this out explicitly and shows three consumer-side patterns.

chrome-devtools-mcp@0.21.0 is pinned in flake.nix instead of tracking
@latest — consumers inherit a tested combination rather than whatever
drifted to the npm registry between runs. The writeShellScriptBin
rather than writeShellApplication choice is deliberate: the latter
pulls shellcheck at eval time (~600ms), which isn't free on a wrapper
that runs on every MCP server startup (see
docs/nix-eval-perf-report.md).

Kolu's own .mcp.json and the ai::mcp-chrome-devtools just recipe
are untouched by this PR. This is a staging demo, not a migration
— it's on the author to extract and wire up the consumer side later.

Try it locally

nix run 'github:juspay/kolu/livid-phase?dir=examples/chrome-devtools-mcp-nix' -- --help

[srid]

Hickey/Lowy Analysis

#	Lens	Finding	Disposition
1	Hickey	mkMcp evaluated twice per system — complects derivation identity with call count	Fixed in this PR (7b752b7, later superseded by 8674657 which actually satisfied the constraint)
2	Hickey	CI smoke-test on the pinned version is documented as a norm, not mechanized	Deferred to extracted repo — noted in README
3	Hickey	No error context when npx fails (raw npx error, no flake/version breadcrumb)	No-op — marginal for a staging demo
4	Lowy	Offline/hermetic fetch as a third volatility axis (npm-fetch strategy) — npx -y hits npm at runtime	Deferred to extracted repo — noted in README

Hickey rationale

The flake's concern separation is structurally sound — version pinning in one place, binary provisioning deferred, shell wrapper kept thin. The original perSystem function was called twice per system (once for packages, once for apps), which re-invoked mkMcp each time and silently regressed the "bind once per system" goal the let-refactor was supposed to achieve. The elegance pass in /code-police caught this and inverted the iteration so perSystem is a single eachSystem result, projected to packages and apps via mapAttrs — now mkMcp pkgs genuinely runs once per system. The rec { ... } that leaked mcp as an output attribute is also gone (now a let-local).

Lowy rationale

The implementation honors its design. MCP version volatility is owned by the flake (mcpVersion = "0.21.0", pinned and bumped deliberately). Chrome provisioning volatility is correctly deferred to the consumer via "$@" passthrough — the README names this boundary and shows three consumer patterns (PATH, custom binary, Playwright resolver) as first-class, with none elevated to "the way." Node.js runtime is encapsulated by nixpkgs (pinned via flake.lock). No Kolu-specific references leak into the flake body — the extraction seam is clean. One future-volatility axis is not yet encapsulated: npx -y assumes network reachability, which won't hold for air-gapped or strict-hermetic consumers; that's a real axis but belongs in the extracted repo, captured as a deferred item in the README.

[srid]

/do results

Step	Status	Duration	Verification
sync	✓	0s	git fetch ok; forge=github; noGit=false
research	✓	1m 41s	Surveyed kolu Nix conventions + APM #655; planned externalization at examples/chrome-devtools-mcp-nix/
branch	✓	17s	Worktree-scoped livid-phase, fresh from master
implement	✓	1m 19s	flake.nix + README + flake.lock; smoke-built via nix flake check
check	✓	12s	just check passed
docs	✓	10s	Example is self-documented
fmt	✓	8s	0/6 files needed reformatting
commit	✓	13s	83e2c19 pushed
hickey+lowy	✓	2m 33s	1 fixed in PR, 2 deferred to extracted repo, 1 no-op
police	✓	3m 35s	Elegance pass caught a real regression (double-eval of mkMcp); 3 commits applied
test	—	15s	Skipped: no relevant e2e scenarios for a standalone flake
create-pr	✓	1m 16s	Draft → ready; hickey/lowy posted as comment
ci	✓	2m 36s	All 10 contexts green on fa26c9f
Total		14m 59s

Slowest step: police (3m 35s)

Optimization suggestions

• police (3m 35s) was the bottleneck, driven by /simplify's three parallel agents catching a real issue I thought hickey+lowy had already fixed (the inverted perSystem / mapAttrs refactor). Running /simplify earlier — e.g. alongside hickey+lowy rather than only in police — would have surfaced the double-eval in one combined pass instead of discovering it post-commit and needing three follow-up commits.
• hickey+lowy (2m 33s) could have been shorter by passing the smaller review model. For a 30-line declarative flake, --review-model=haiku would likely have returned the same findings at lower latency.
• CI (2m 36s) is dominated by cross-system builds; no room to trim for a flake-only PR short of splitting just ci into flake-scope-aware subsets — not worth it for a one-off.

Workflow completed at 2026-04-21T15:17:00Z.

[srid]

https://old.reddit.com/r/ClaudeAI/comments/1oh32hh/ive_successfully_converted_chromedevtoolsmcp_into/