Skip to content

fix: bare /config renders live state, not a frozen startup snapshot (gh #97) - #98

Merged
dkedar7 merged 1 commit into
mainfrom
fix/97-config-live-view
Jul 25, 2026
Merged

dkedar7 merged 1 commit into
mainfrom
fix/97-config-live-view

Conversation

@dkedar7

@dkedar7 dkedar7 commented Jul 25, 2026

Copy link
Copy Markdown
Owner

Summary

In the interactive loop, the bare /config full-table view printed _resolved_config_report — a string snapshotted at startup and never updated — while every other reader and setter uses the live context. So after any runtime mutation the full table contradicted /status, the single-key /config <key> read, and even the ✓ Set … line /config itself had just printed, and it carried a wrong source label ([default] for a value the user had actually overridden). Fixes #97.

Repro A — verbose (was)

❯ /verbose on         → ✓ Verbose mode enabled
❯ /config verbose     → verbose: True
❯ /status             → Verbose:  on
❯ /config             → verbose = False   [default]   ← WRONG (frozen snapshot)

After

❯ /config             → verbose = True    [override]  ← agrees with /status & /config verbose

Repro B (thread_id) likewise: after /reset, the bare /config [configurable] table now shows the new thread_id instead of the pre-reset one.

What changed

Bare /config now re-renders the one describe() diagnostic (the same renderer --show-config uses) from the CodeConfig resolved at startup, overlaid with live state:

  • verbose from context["verbose"], relabelled [override] (never [default]) when it differs from the resolved value;
  • the live [configurable] values overlaid onto the startup key set, so a /reset thread_id shows through.

Crucially it re-renders the startup-resolved cfg (whose per-field provenance is frozen) rather than re-resolving, so it still can't pick up the LANGSTAGE_WORKSPACE_ROOT that apply_workspace() self-publishes — the #64 fix holds and the no-mutation startup table stays byte-for-byte identical to --show-config. Same "two provenance views disagree" family as #64 / #66 / #79, now closed for the full /config table. The non-interactive --show-config flag is unaffected.

Tests

Three regression tests drive the real interactive loop (CliRunner + piped commands): flip verbose via /verbose and /config verbose on then assert the bare /config table shows True [override] and agrees with /status + the single-key read; and a /reset test asserts the [configurable] thread_id tracks the reset. All three fail before the fix, pass after.

Full suite: 146 passed (143 baseline + 3 new). ruff check . and ruff format --check . both clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_011HWCfJii6gXd3XL3Gq3W8B

#97)

The full-table `/config` view printed `_resolved_config_report` — a string
snapshotted at startup and never updated — while every other reader and setter
uses the live `context`: `/config verbose on` sets `context["verbose"]`,
`/config verbose` and `/status` read it back, and `/reset` mutates
`context["config"]["configurable"]["thread_id"]`. So after `/verbose on` the
table still showed `verbose = False [default]` even as `/status` said `on` and
`/config verbose` said `True`, and after `/reset` it kept printing the pre-reset
`thread_id`. The frozen string also carried a wrong SOURCE label — `[default]`
for a value the user had overridden — so a user who set a value and re-ran
`/config` to confirm saw it reported as unset and could conclude the set had
silently failed.

Bare `/config` now RE-RENDERS the one `describe()` diagnostic (the same renderer
`--show-config` uses) from the `CodeConfig` resolved at startup, overlaid with
live state: `verbose` from `context["verbose"]` (relabelled `[override]`, never
`[default]`, when it differs from the resolved value) and the live
`[configurable]` values (so a `/reset` thread_id shows through). Crucially it
re-renders the startup-resolved cfg — whose per-field provenance is frozen —
rather than RE-RESOLVING, so it still can't pick up the
`LANGSTAGE_WORKSPACE_ROOT` that `apply_workspace()` self-publishes: the #64 fix
holds and the no-mutation startup table stays byte-for-byte identical to
`--show-config`. Same "two provenance views disagree" family as #64 / #66 / #79,
now closed for the full `/config` table. `--show-config` is unaffected.

Regression tests drive the real interactive loop: flip verbose (via `/verbose`
and `/config verbose on`), then assert the bare `/config` table reflects it with
an `[override]` source and agrees with `/status` and the single-key read; and a
`/reset` test asserts the `[configurable]` thread_id tracks the reset. All three
fail before the fix and pass after.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011HWCfJii6gXd3XL3Gq3W8B
@dkedar7
dkedar7 merged commit 4497faa into main Jul 25, 2026
6 checks passed
@dkedar7
dkedar7 deleted the fix/97-config-live-view branch July 25, 2026 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant