[max-sixty]

The gap

The global --config-set <toml> flag (inline config override, added in #3138, shipped in v0.61.0) bypassed the config deprecation-migration layer. A deprecated key passed via --config-set fell through as an unknown field and was silently dropped — UserConfig has no deny_unknown_fields, and the --config-set layer never ran the unknown-field warning — so the override had no effect and no signal. The same key in a config file is rewritten to its canonical form by migrate_content() before serde parses it, so it works there.

For example, before this change wt --config-set 'merge.no-ff = true' … left merge.ff at its default (the deprecated no-ff was ignored), whereas [merge]\nno-ff = true in a config file correctly resolved to merge.ff = false.

The fix

Route each --config-set fragment through the same migrate_content() config files use — structural and silent rewrites only, no UpdateOnly — before parsing and deep-merging it (apply_cli_overrides in src/config/user/mod.rs). This is the same shape the test-only load_from_str already uses: migrate, then parse. deprecation.rs is untouched.

Two decisions worth calling out:

• Migrate each fragment, not the merged document. Because migrate_negated_bool keeps a pre-existing canonical key when both forms are present, migrating the merged table would let a lower layer's merge.ff win over a --config-set 'merge.no-ff = …' override. Migrating each fragment in isolation and then deep-merging preserves the documented layer precedence (config files → WORKTRUNK_* env → --config-set).
• The migration is silent (uses migrate_content, not check_and_migrate). The deprecation warning invariant is file-scoped — "a warning fires exactly when wt config update would change the file" — and an inline override has no file to materialize, so a "run wt config update" hint would point at a file the key isn't in. Deprecated keys via --config-set previously vanished silently; they now take effect silently.

Malformed fragments are unaffected: migrate_content returns invalid TOML unchanged, so the existing parse-error path still drops the whole --config-set layer with an attributed LoadError::CliOverride warning, preserving the lower layers.

Tests

• Unit (src/config/user/tests.rs): test_cli_override_migrates_deprecated_keys (merge.no-ff → ff = false, switch.no-cd → cd = false, no warnings) and test_cli_override_deprecated_key_wins_over_lower_canonical (precedence).
• Integration (tests/integration_tests/switch.rs): test_switch_config_set_migrates_deprecated_no_cd — end-to-end proof via the cd directive (the migrated switch.cd = false suppresses the "Cannot change directory" line). This is the bug-catcher: reverting the one-line fix reintroduces the line and fails the snapshot.
• Integration (tests/integration_tests/list_config.rs): test_list_config_cli_override_deprecated_key_silently_migrated — guards the "layer accepted, no warning" contract among the other --config-set tests. (A wt list snapshot can't observe a merge key, so the behavioral proof lives in the switch test.)

Known adjacent gap (out of scope)

The WORKTRUNK_* env-var layer still does not migrate deprecated keys: WORKTRUNK__MERGE__NO_FF=true lands as merge.no-ff and is silently dropped, the same defect this PR fixes for --config-set. That path is a different shape (per-var typed/string probing against the file table, not a TOML fragment) and can't reuse the one-line migrate_content insertion, so it's left for a follow-up rather than forced into this change. The inline-table form (merge = { no-ff = true }) is likewise not migrated — a pre-existing migrate_content limitation that affects config files too (documented at deprecation.rs:500-504); the dotted form the --config-set help text shows works.

This was written by Claude Code on behalf of max