Appearance
Config explain
Status: present state, partial. There is no dedicated
mx config explainormatrix run --explaincommand in the current code. This page documents the four CLI surfaces that together let you reconstruct what a runtime will see, plus a target-state outline for a future unified command.
Present-state surfaces
mx config — CLI config
bash
mx config get registry
mx config set registry https://registry.example.com/api/packages/...
mx config list
mx config resetSource: packages/mx-cli/src/commands/config.ts. The CLI config is the per-user config used by mx publish/mx install/mx search. Today it has one key: registry. Default is https://registry.hivecast.ai/api/packages/open-matrix/npm/ (packages/mx-cli/src/utils/config-store.ts:DEFAULT_PACKAGE_REGISTRY).
The CLI config file lives at one of:
--config-file <path>if explicitly passed$MATRIX_CLI_CONFIGif set<MATRIX_HOME>/cli-config.json(default~/.matrix/cli-config.json)
mx info <packageName> — installed package metadata
bash
mx info @open-matrix/chat --packages-dir /tmp/matrix-home/packages/globalPrints the package directory, whether it has matrix.json, and the package version it resolves. Source: packages/mx-cli/src/commands/info.ts.
mx validate — manifest sanity check
bash
cd projects/matrix-3/packages/<my-pkg>
mx validate
mx validate --json | jq .diagnosticsReports manifest validation errors. Useful for confirming that the manifest you're running matches the one the validator expects.
Direct file inspection — environment files
bash
cat .matrix/dev.environment.json | jq .The file is the literal source of truth for runtime.root, NATS mode, runtime id, and HTTP port when running with --env dev. There is no merge step at this layer; what's in the file is what the runner sees.
Direct file inspection — host.json
bash
cat /tmp/matrix-home/host.json | jq .transporthost.json is the Host-level transport/auth/storage config. Edits here are picked up only on hivecast stop/hivecast start.
How the layers compose
For a runtime started by matrix run . --env dev:
┌──────────────────────────────┐
│ matrix.json │ package identity, components,
│ └─ config.{schema,defaults} │ defaults+schema for package config
└──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ .matrix/dev.environment.json │ wire root, NATS, http port,
└──────────────────────────────┘ runtimeId
│
▼
┌──────────────────────────────┐
│ env vars (config.providers) │ per-process overrides
│ + file path from $MATRIX_* │
│ + system.config service │
└──────────────────────────────┘
│
▼
what the actor seesRead it bottom-up to debug: if an actor sees an unexpected value, walk the providers in order, then the env file, then the defaults, then the schema for shape mismatches.
Target state — one command
A future mx run --explain (or mx config explain) would:
- Resolve the manifest, env file, and providers in order.
- Print the merged config that an actor would receive.
- Annotate each value with its source layer.
- Validate against
config.schemaand report any drift.
This is filed as a quality-of-life follow-up; not in code today. Use the four surfaces above as the workaround.
A practical debugging recipe
When an actor misbehaves:
mx validate— confirm the manifest is structurally valid.cat matrix.json | jq .config— see what providers are declared.cat .matrix/<env>.environment.json— see the wire/runtime identity.env | grep MATRIX_<PKG>_— see what the env provider would pick up.mx info <packageName>(when running against a Host) — confirm which copy of the package the runtime resolved.hivecast invoke system.config '<op>' '{"namespace":"@open-matrix/<pkg>"}'if you use a config service — confirm what it returns.
See also
- Authoring → Config contract
- Reference → Config contract schema
- Running → Verify
- Reference → CLI reference
Source:
projects/matrix-3/packages/mx-cli/src/commands/config.tsformx config;packages/mx-cli/src/commands/info.tsformx info;packages/mx-cli/src/commands/validate.tsformx validate.