agents config set reports Previous: (unset) instead of the effective previous value #4358

Open
opened 2026-04-08 00:15:22 +00:00 by brent.edwards · 2 comments
Member

Metadata

  • Commit Message: fix(config): show effective previous value when setting a config key
  • Branch: fix/config-set-previous-value

Background and Context

When agents config set updates a configuration key, it displays a Previous: field in its output. However, the command only checks whether the key was previously explicitly written to the config file — it does not account for default values. When a key has a default but has never been explicitly set, the command incorrectly reports Previous: (unset) even though an effective value was in use. This is misleading: users are shown that no prior value existed when in fact the key was active at its default.

Current Behavior

In a fresh environment, agents config get plan.tool.max-retries correctly reports the effective value as 3 with Source: default. Running agents config set plan.tool.max-retries 1 immediately afterward reports Previous: (unset) rather than Previous: 3.

Reproduction steps (run in a fresh docker exec to ensure a clean environment with no prior config):

mkdir -p ~/test/20260407-01
cd ~/test/20260407-01
mkdir data
uv venv
source .venv/bin/activate
uv pip install /app
agents init --yes
agents config get plan.tool.max-retries

Output of agents config get:

╭─── Configuration Value ────╮
│ Key: plan.tool.max-retries │
│ Value: 3                   │
│ Source: default            │
│ Type: int                  │
╰────────────────────────────╯

Then:

agents config set plan.tool.max-retries 1

Actual output:

╭── Configuration Updated ───╮
│ Key: plan.tool.max-retries │
│ Value: 1                   │
│ Previous: (unset)          │
│ Source: config_file        │
│ Scope: global              │
╰────────────────────────────╯

Expected Behavior

agents config set should report the effective previous value — the value that agents config get would have returned immediately before the set operation — regardless of whether it came from the config file or from a default.

Expected output:

╭── Configuration Updated ───╮
│ Key: plan.tool.max-retries │
│ Value: 1                   │
│ Previous: 3                │
│ Source: config_file        │
│ Scope: global              │
╰────────────────────────────╯

Acceptance Criteria

  • Running agents config set on a key whose prior value came from a default reports that default under Previous:, not (unset).
  • Running agents config set on a key that was previously explicitly set in the config file reports the explicitly set value under Previous:.
  • Running agents config set on a key that has no default and has never been set continues to report Previous: (unset).

Supporting Information

The Source: default field in agents config get output confirms a default is in effect before the set operation. The bug is that agents config set does not resolve the effective value via the same code path as agents config get when capturing the prior state.

Subtasks

  • Locate the code path in agents config set that reads the previous value before writing the update
  • Fix the previous-value lookup to resolve the effective value (including defaults) rather than only the explicitly stored config-file value
  • Tests (Behave): Add scenario verifying Previous: shows the default value when overriding a key that was never explicitly set
  • Tests (Behave): Add scenario verifying Previous: (unset) appears only when no effective value existed before the set
  • Tests (Robot): Add integration test covering the Previous: field in agents config set output
  • Verify coverage ≥97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
## Metadata - **Commit Message**: `fix(config): show effective previous value when setting a config key` - **Branch**: `fix/config-set-previous-value` ## Background and Context When `agents config set` updates a configuration key, it displays a `Previous:` field in its output. However, the command only checks whether the key was previously *explicitly written* to the config file — it does not account for default values. When a key has a default but has never been explicitly set, the command incorrectly reports `Previous: (unset)` even though an effective value was in use. This is misleading: users are shown that no prior value existed when in fact the key was active at its default. ## Current Behavior In a fresh environment, `agents config get plan.tool.max-retries` correctly reports the effective value as `3` with `Source: default`. Running `agents config set plan.tool.max-retries 1` immediately afterward reports `Previous: (unset)` rather than `Previous: 3`. **Reproduction steps** (run in a fresh `docker exec` to ensure a clean environment with no prior config): ``` mkdir -p ~/test/20260407-01 cd ~/test/20260407-01 mkdir data uv venv source .venv/bin/activate uv pip install /app agents init --yes agents config get plan.tool.max-retries ``` Output of `agents config get`: ``` ╭─── Configuration Value ────╮ │ Key: plan.tool.max-retries │ │ Value: 3 │ │ Source: default │ │ Type: int │ ╰────────────────────────────╯ ``` Then: ``` agents config set plan.tool.max-retries 1 ``` **Actual output:** ``` ╭── Configuration Updated ───╮ │ Key: plan.tool.max-retries │ │ Value: 1 │ │ Previous: (unset) │ │ Source: config_file │ │ Scope: global │ ╰────────────────────────────╯ ``` ## Expected Behavior `agents config set` should report the *effective* previous value — the value that `agents config get` would have returned immediately before the set operation — regardless of whether it came from the config file or from a default. **Expected output:** ``` ╭── Configuration Updated ───╮ │ Key: plan.tool.max-retries │ │ Value: 1 │ │ Previous: 3 │ │ Source: config_file │ │ Scope: global │ ╰────────────────────────────╯ ``` ## Acceptance Criteria - Running `agents config set` on a key whose prior value came from a default reports that default under `Previous:`, not `(unset)`. - Running `agents config set` on a key that was previously explicitly set in the config file reports the explicitly set value under `Previous:`. - Running `agents config set` on a key that has no default and has never been set continues to report `Previous: (unset)`. ## Supporting Information The `Source: default` field in `agents config get` output confirms a default is in effect before the set operation. The bug is that `agents config set` does not resolve the effective value via the same code path as `agents config get` when capturing the prior state. ## Subtasks - [ ] Locate the code path in `agents config set` that reads the previous value before writing the update - [ ] Fix the previous-value lookup to resolve the effective value (including defaults) rather than only the explicitly stored config-file value - [ ] Tests (Behave): Add scenario verifying `Previous:` shows the default value when overriding a key that was never explicitly set - [ ] Tests (Behave): Add scenario verifying `Previous: (unset)` appears only when no effective value existed before the set - [ ] Tests (Robot): Add integration test covering the `Previous:` field in `agents config set` output - [ ] Verify coverage ≥97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done.
brent.edwards added this to the v3.7.0 milestone 2026-04-08 00:15:22 +00:00
brent.edwards changed title from 'agents config set` does not show correct previous values. to agents config set reports Previous: (unset) instead of the effective previous value 2026-04-08 00:16:42 +00:00
Owner

Issue reviewed and triaged.

This issue is well-formed: it has clear background, reproduction steps, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done.

  • Priority: Medium — misleading UX when overriding a key with a default value; not data-loss, but confusing.
  • Story Points: 1 (XS) — the fix is to resolve the effective value via the same code path as config get before writing.
  • Next step: This issue is now verified and ready for implementation.

Transitioning to State/Verified.


Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: human-liaison

Issue reviewed and triaged. This issue is well-formed: it has clear background, reproduction steps, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done. - **Priority**: Medium — misleading UX when overriding a key with a default value; not data-loss, but confusing. - **Story Points**: 1 (XS) — the fix is to resolve the effective value via the same code path as `config get` before writing. - **Next step**: This issue is now verified and ready for implementation. Transitioning to `State/Verified`. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: human-liaison
Owner

Issue triaged by project owner:

  • State: Verified — Clear UX bug with reproduction steps
  • Priority: Medium (already set) — Cosmetic but confusing for users
  • Milestone: v3.7.0 (already set)
  • Story Points: 1 — XS (already set)
  • MoSCoW: Should Have (already set) — Important for user experience but not blocking
  • Assignee: HAL9000

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified ✅ — Clear UX bug with reproduction steps - **Priority**: Medium ✅ (already set) — Cosmetic but confusing for users - **Milestone**: v3.7.0 ✅ (already set) - **Story Points**: 1 — XS (already set) - **MoSCoW**: Should Have ✅ (already set) — Important for user experience but not blocking - **Assignee**: HAL9000 --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core#4358
No description provided.