Summary
bd config set <key> <value> writes any string as a key into config.yaml without validating against the known namespace list documented in bd config --help (export.*, dolt.*, jira.*, linear.*, github.*, custom.*, status.*, doctor.suppress.*, plus a handful of top-level keys like auto_compact_enabled, schema_version, etc.).
Typos and guesses become silent no-ops that persist in config.yaml forever, with no signal that the user didn't actually change the behavior they intended to change.
Reproducer (bd 1.0.2 on Windows 11, verified just now)
$ bd --version
bd version 1.0.2 (a3f834b3)
$ bd config set totally.bogus.nonsense "foo"
Set totally.bogus.nonsense = foo
$ bd config list | grep bogus
totally.bogus.nonsense = foo
No warning. No error. No indication that totally.bogus is not a recognized namespace. The entry persists in .beads/config.yaml until manually unset.
Real-world impact (how I ran into it)
Post-upgrade to v1.0.2, I was trying to silence the new auto-export: git add failed warning (my .beads/issues.jsonl is in .git/info/exclude because I'm on --server mode with Dolt as source of truth — see #3142 context).
I guessed the key was export.auto-export:
$ bd config set export.auto-export false
Set export.auto-export = false (in config.yaml)
bd accepted it, so I assumed it worked. But the warning kept firing on the next write command. Had to dig through bd config --help to discover the real key is export.auto — no -export suffix.
Debug cost on my side was ~5 minutes. The fail mode is entirely silent: valid-looking command, valid-looking feedback, and a warning that still fires but isn't obviously tied to the bogus key I just set.
Expected behavior
One of (in order of preference):
-
Reject with an error naming the valid top-level namespaces:
Error: unknown config key 'export.auto-export'.
Valid namespaces: export.*, dolt.*, jira.*, linear.*, github.*, custom.*, status.*, doctor.suppress.*
Run 'bd config --help' for the full key list.
-
Warn on stderr but still write (less strict, preserves current behavior for scripts that might already depend on arbitrary-key acceptance):
Warning: 'export.auto-export' is not a recognized config key. Stored anyway. Did you mean 'export.auto'?
-
Did-you-mean suggestion using Levenshtein on the valid key list:
Error: unknown config key 'export.auto-export'. Did you mean 'export.auto'?
Escape hatch for the custom.* namespace (which is documented as user-extensible) and for third-party integrations can be the existing custom. prefix — anything under custom.* bypasses validation.
Suggested fix direction
In the bd config set handler (cmd/bd/config.go or similar), after parsing the key, validate against a static list of known top-level prefixes. Accept custom.* verbatim. Reject or warn on the rest depending on which option above the maintainers prefer.
Happy to submit a PR if there's interest — same pattern as #3188 (I filed that one). Want to confirm the option preference before I start on it though, since the three options have meaningfully different compat implications.
Priority
Low — not a crash, not data loss, not a security issue. Just a usability paper cut that cost me time this afternoon and will almost certainly cost other users the same.
Summary
bd config set <key> <value>writes any string as a key intoconfig.yamlwithout validating against the known namespace list documented inbd config --help(export.*,dolt.*,jira.*,linear.*,github.*,custom.*,status.*,doctor.suppress.*, plus a handful of top-level keys likeauto_compact_enabled,schema_version, etc.).Typos and guesses become silent no-ops that persist in
config.yamlforever, with no signal that the user didn't actually change the behavior they intended to change.Reproducer (bd 1.0.2 on Windows 11, verified just now)
No warning. No error. No indication that
totally.bogusis not a recognized namespace. The entry persists in.beads/config.yamluntil manually unset.Real-world impact (how I ran into it)
Post-upgrade to v1.0.2, I was trying to silence the new
auto-export: git add failedwarning (my.beads/issues.jsonlis in.git/info/excludebecause I'm on--servermode with Dolt as source of truth — see #3142 context).I guessed the key was
export.auto-export:bd accepted it, so I assumed it worked. But the warning kept firing on the next write command. Had to dig through
bd config --helpto discover the real key isexport.auto— no-exportsuffix.Debug cost on my side was ~5 minutes. The fail mode is entirely silent: valid-looking command, valid-looking feedback, and a warning that still fires but isn't obviously tied to the bogus key I just set.
Expected behavior
One of (in order of preference):
Reject with an error naming the valid top-level namespaces:
Warn on stderr but still write (less strict, preserves current behavior for scripts that might already depend on arbitrary-key acceptance):
Did-you-mean suggestion using Levenshtein on the valid key list:
Escape hatch for the
custom.*namespace (which is documented as user-extensible) and for third-party integrations can be the existingcustom.prefix — anything undercustom.*bypasses validation.Suggested fix direction
In the
bd config sethandler (cmd/bd/config.goor similar), after parsing the key, validate against a static list of known top-level prefixes. Acceptcustom.*verbatim. Reject or warn on the rest depending on which option above the maintainers prefer.Happy to submit a PR if there's interest — same pattern as #3188 (I filed that one). Want to confirm the option preference before I start on it though, since the three options have meaningfully different compat implications.
Priority
Low — not a crash, not data loss, not a security issue. Just a usability paper cut that cost me time this afternoon and will almost certainly cost other users the same.