Mux module

[bpmct]

A discussion dedicated to the Mux module. Share your thoughts, questions, and feedback here.

Module Scorecard

Presentation & Onboarding	Agent Integration	Credential Hygiene	Restricted-Environment Readiness	Engineering Quality	Overall
25 / 25	15 / 25	20 / 20	18 / 20	10 / 10	88 / 100

Drilldown

Presentation & Onboarding — 25 / 25

Criterion	Max	Score	Notes
Configuration-mode examples	12	12	README provides examples for all major modes: basic usage, version pinning, custom package manager (npm/pnpm/bun), custom registry, cached installation, skip install, restart behavior, custom port, project opening, and arbitrary arguments. Each has sensible defaults.
Coder-context framing	8	8	README clearly states "Automatically install and run Mux in a Coder workspace," names both Coder and Mux, explains Mux is a desktop application for parallel agentic development, and shows Coder provides the workspace infrastructure.
Visual preview	5	5	README includes  showing the module in action.

Agent Integration — 15 / 25

Criterion	Max	Score	Notes
AI governance	10	0	No documentation of Coder AI Gateway or Agent Firewall support. The module generates a per-instance auth token for cross-site request protection, but this is module-level authentication, not AI governance integration.
Dashboard entry point	5	5	coder_app resource configured with proper URL, healthcheck, icon, and configurable open_in behavior (tab or slim-window).
Session continuity	5	5	README documents restart behavior: "Enable automatic restarts after Mux exits...The launcher waits for restart_delay_seconds, removes ~/.mux/server.lock, and starts Mux again." The restart mechanism preserves Mux's internal session state across process restarts.
Managed configuration	5	5	README documents managed configuration via add_project (opens a project on launch), additional_arguments for arbitrary mux server arguments, port, and the module manages the auth token via MUX_SERVER_AUTH_TOKEN environment variable.

Credential Hygiene — 20 / 20

Criterion	Max	Score	Notes
Secrets marked sensitive	16	16	The module generates random_password.mux_auth_token for authentication. While not marked sensitive = true explicitly on the resource (random_password doesn't expose the result in plan output by default), README examples contain no inline secrets or placeholder keys. All examples use module-managed authentication.
Non-hardcoded auth path	4	4	Module automatically generates a per-instance auth token via random_password, eliminating the need for users to paste keys. The token is process-scoped and passed via environment variable, avoiding shared credentials.

Restricted-Environment Readiness — 18 / 20

Criterion	Max	Score	Notes
Mirrorable artifact source	10	10	registry_url variable (default https://registry.npmjs.org) overrides the npm registry URL used for installation. The script uses ${REGISTRY_URL} throughout install paths for both package manager installs and direct tarball downloads. Test coverage confirms custom registry usage.
Bring-your-own binary	5	5	install = false variable documented in README: "Run without installing from the network (requires Mux to be pre-installed)". Example shows usage. Script checks for existing binary when OFFLINE = true.
Egress transparency	3	1.5	No dedicated README section enumerating external endpoints. Endpoints are scattered across examples and inferable from code (registry.npmjs.org, nodejs.org for Node bootstrap), but not consolidated in a network/air-gapped section.
Runs without sudo	2	2	Scripts never invoke sudo. Installation uses package managers or curl/tar, server launch uses nohup/bash, all as the workspace user. No privilege escalation required.

Engineering Quality — 10 / 10

Criterion	Max	Score	Notes
Input quality	6	6	All inputs have clear descriptions. Sensible defaults throughout (port 4000, install_version "next", package_manager "auto"). Validation on package_manager (enum), share (enum), open_in (enum), restart_delay_seconds (>= 0), max_restart_attempts (whole number >= 0). Lifecycle precondition prevents use_cached with install = false.
Test coverage	4	4	.tftest.hcl covers business logic: required vars, conflicting options, custom ports, auth token presence, argument parsing, restart behavior, validation failures, package manager selection, registry URL handling. TypeScript tests in main.test.ts cover end-to-end scenarios: default install, tarball fallback, argument parsing, signal-based exits, restart logic with caps, npm/package manager installs.

Overall — 88 / 100

---

Scored against SCORECARD.md on 2026-08-03 with claude-sonnet-4-5.