fix: --config flag now fully overrides ~/.strix/cli-config.json

[octo-patch]

Fixes #377

Problem

When --config custom.json is provided, Strix still applies settings from ~/.strix/cli-config.json for any keys that are absent from the custom config file.

Root cause: apply_saved_config() is called at module import time (before args are parsed), loading ~/.strix/cli-config.json and setting those env vars in os.environ. Later, apply_config_override() loads the custom config and re-applies it with force=True, overwriting keys that exist in the custom file — but vars that were set from the default file and are missing from the custom file remain in os.environ unchanged.

Solution

Track which env vars were actually set by the initial default-config load in Config._applied_from_default. In apply_config_override, clear those vars from os.environ before applying the custom config. This ensures:

• Keys present only in ~/.strix/cli-config.json are cleared (no leakage).
• Keys present only in the custom config are applied as usual.
• User-set env vars (e.g. export STRIX_LLM=...) are never cleared — they were not set by apply_saved_config, so they are not in _applied_from_default.

Changes

• strix/config/config.py: add Config._applied_from_default class var; populate it in apply_saved when loading the default config.
• strix/interface/main.py: clear _applied_from_default entries in apply_config_override before applying the custom config.

Testing

Manually verified with two config files:

// ~/.strix/cli-config.json
{"env": {"STRIX_LLM": "default-model", "LLM_API_BASE": "https://default.api"}}

// custom.json
{"env": {"STRIX_LLM": "custom-model"}}

Before fix: running strix --config custom.json still inherited LLM_API_BASE from the default file.
After fix: LLM_API_BASE is not set, only STRIX_LLM=custom-model is applied from the custom file.

[greptile-apps]

Greptile Summary

This PR fixes env-var leakage when --config is passed by tracking which vars were set during the initial default-config load (_applied_from_default) and clearing them before applying the custom config. The logic, gating condition, and new test are all correct for the primary use case.

Confidence Score: 5/5

Safe to merge; the fix is correct for the described scenario and the test covers the regression path.

The one comment is a speculative edge case (consecutive apply_config_override calls) that is unlikely to occur in the CLI's single---config usage model; all remaining concerns are P2.

No files require special attention.

Important Files Changed

Filename	Overview
strix/config/config.py	Adds _applied_from_default ClassVar to track env vars set during the initial default-config load; logic correctly gates recording to non-forced, non-override calls.
strix/interface/main.py	Clears _applied_from_default entries before applying the custom config; consecutive --config calls can still leak vars from the first custom config into the second.
tests/config/test_config_override.py	New test correctly sets up isolated state, explicitly calls apply_saved_config(), and asserts both the override and the cleared-default-only var; covers the primary regression path well.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: strix/interface/main.py
Line: 531-539

Comment:
**Consecutive `--config` calls leak vars from the first custom config**

After `apply_config_override` runs once, `_applied_from_default` is reset to `{}`. If it is called a second time (e.g. an integration path that re-invokes argument processing), vars that were applied with `force=True` from the *first* custom config are not tracked anywhere, so they won't be cleared before the second custom config is applied — reproducing the same leakage the fix intends to prevent, just one level up.

A minimal guard would be to also track what `apply_saved_config(force=True)` applied and store it back into `_applied_from_default`, or at least clear all previously-tracked vars from `os.environ` including any set by a prior custom-config load. If `--config` can only ever be passed once per process lifetime this is a non-issue, but the function has no guard against being called twice.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (3): Last reviewed commit: "Make config override test setup explicit" | Re-trigger Greptile}

[bearsyankees]

@greptile

[bearsyankees]

@greptile

[bearsyankees]

LGTM! Thanks @octo-patch