[Bug] --dump-config shows telemetry enabled when DSH_TELEMETRY_DISABLED is set (0.2.1-rc.2)

[mertkayacs]

--dump-config prints the session-telemetry-otel row as enabled when DSH_TELEMETRY_DISABLED is set. A boot of the same command line disables that row, so the dump shows a composition the launcher never mounts.

Environment

• source checkout of master @ 687f282 (dsh --version: 0.2.1-rc.2), Linux x64, Node 22.22.3, fresh DSH_HOME
• no API key and no profile boot needed

Steps

export DSH_HOME="$(mktemp -d)"
export DSH_TELEMETRY_DISABLED=1
node --import tsx/esm apps/cli/src/bin.ts --dump-config --profile web \
  | awk '/^- id: session-telemetry-otel/{f=1} f&&/^- id:/&&!/session-telemetry-otel/{exit} f'

With the installed package: DSH_TELEMETRY_DISABLED=1 dsh --profile web --dump-config. --dump-default-config behaves the same.

Current behavior

The telemetry row is printed with no disabled: true:

- id: session-telemetry-otel
  name: '@deepseek-ai/dsh-session-telemetry-otel'
  config:
    mode: !!js process.env.DSH_TELEMETRY_MODE || 'FEEDBACK_ONLY'
    ...

Expected behavior

dsh -h describes --dump-config as "print the composed profile tree and exit". Boot composes the bundle, profile, home, and --patch layers and then appends the telemetry opt-out patch last: readProfilePatches (packages/boot/app-boot/src/profile-context.ts:74-85) is passed to boot by the launcher (apps/cli/src/profile-boot.ts:321-323), and apps/cli/tests/resolved-profile-boot.spec.ts already asserts the composed row ends up disabled. The reference README documents "any non-empty DSH_TELEMETRY_DISABLED disables its row" (apps/cli/reference/README.md). The dump collects the same layer stack, so with the variable set it should print the row with disabled: true under a DSH_TELEMETRY_DISABLED patch comment, and print nothing extra when the variable is unset.

--dump-config is the natural way to check that the opt-out took effect, and today it reports the opposite of what boots.

Root cause and suggested fix

collectConfigDumpLayers (apps/cli/src/dump-config.ts:51-75) returns the file-backed layers only. The minimal fix appends, after the overlay loop, the same patch boot appends:

const telemetryPatch = resolveTelemetryPatch(
  process.env.DSH_TELEMETRY_DISABLED,
  composeEntries([layers.flatMap(layer => layer.patches)]).some(row => row.id === 'session-telemetry-otel'),
)
if (telemetryPatch !== undefined) layers.push({ label: 'DSH_TELEMETRY_DISABLED', patches: [telemetryPatch] })

I verified this locally: with those lines the row prints disabled: true in both dump modes, output is unchanged when the variable is unset, a regression spec over collectConfigDumpLayers fails on master and passes with the change, the neighboring CLI specs (7 files, 125 tests) stay green, and pnpm run typecheck passes.

[PerryLink]

Confirmed, and the divergence is structural rather than a rendering bug: the boot path applies the switch, the dump path has no access to it.

Booting passes the environment value into composition:

// apps/cli/src/profile-boot.ts:321
overlays: composed.overlays, telemetryDisabledEnv: process.env.DSH_TELEMETRY_DISABLED,

runDumpConfig does not go through that path. apps/cli/src/dump-config.ts composes layers directly — loadOptionalPatches, the profile's own patch file, each --patch overlay — and hands them to renderConfigDump (:11-17). The module is 77 lines and contains no reference to the telemetry switch, so there is nothing in the dump that could turn the row off.

That matches what you see: the dump shows the composition before the telemetry decision, and the boot shows it after. Neither is wrong about its own input; they are two different compositions being printed with the same label.

The fix is small: pass telemetryDisabledEnv into runDumpConfig and apply the same switch while building the layer list, so both paths consume one function instead of two. The alternative — documenting that --dump-config excludes the telemetry switch — is worse, because the dump is the thing people use to answer "what will actually boot".

Worth adding to the report: because the switch is applied as a layer, any other environment-driven layer added later will diverge the same way. If the dump is meant to be a faithful preview, the switch logic should live in one place that both entry points call, not in the boot-only path.