[seattled23]

Summary

Two related defects mean the [limits] config section does not work, and setting it partially breaks the rest of your config too.

1. grep_max_results is dead config

It is declared, defaulted, and printed by rtk config — but never read anywhere in the codebase:

$ rg 'grep_max_results' src/
src/core/config.rs:125:    pub grep_max_results: usize,
src/core/config.rs:139:            grep_max_results: 200,

(grep_max_per_file is read, in search.rs, so the section looks like it works.)

The cap actually applied comes from clap's hardcoded default on rtk grep:

#[arg(short, long, default_value = "200")]
max: usize,

So setting the documented key has no effect. Commands::Rg hardcoded 200 the same way.

Before:

$ printf '[limits]\ngrep_max_results = 5000\ngrep_max_per_file = 500\n' > ~/.config/rtk/config.toml
$ rtk grep -n 'the' ./skills | wc -l
202                      # still capped at 200
$ rtk grep -n 'the' ./skills -m 5000 | wc -l
4869                     # only the CLI flag works

After — max becomes Option<usize> and falls back to the config value, so precedence is CLI > config > default:

$ # grep_max_results = 3   -> 3 results
$ # grep_max_results = 400 -> all 182 results
$ # grep_max_results = 3, with --max 50 -> 50 results   (CLI still wins)

2. A partial [limits] section breaks the whole config

LimitsConfig has no serde defaults, so every one of its five fields is mandatory. A config that sets only one limit fails to deserialize — and because that fails the entire Config::load(), every other section silently reverts to defaults, including [hooks] transparent_prefixes and exclude_commands.

$ printf '[limits]\ngrep_max_results = 5000\n' > ~/.config/rtk/config.toml
$ rtk config
rtk: TOML parse error at line 1, column 1
     missing field `status_max_files`

That is a confusing failure on its own, but the dangerous part is the silent blast radius onto unrelated sections.

#[serde(default)] on the struct fixes it, and matches what TelemetryConfig, HooksConfig, and every field of Config already do.

Changes

• src/core/config.rs — #[serde(default)] on LimitsConfig
• src/main.rs — rtk grep --max is now Option<usize>, falling back to limits.grep_max_results; Commands::Rg uses the config value instead of a hardcoded 200
• two regression tests: a partial [limits] parses and keeps other fields' defaults, and it no longer clobbers [hooks]

Verification

cargo fmt --all -- --check clean, cargo clippy --all-targets no warnings.

cargo test --bin rtk → 2526 passed.

Two pre-existing failures in hooks::rewrite_cmd::tests::unattestable_passthrough (test_plain_command_still_rewrites, test_fd_dup_redirect_still_rewrites) reproduce identically on pristine master with my changes stashed. They read the real user config, so they pass or fail depending on whether ~/.config/rtk/config.toml exists on the machine running them — worth isolating separately, but out of scope here.

Why this mattered

Found while debugging what looked like rtk grep silently dropping matches. It does not drop them — but with grep_max_per_file = 25 unfixable via config, a file with 30 matches shows 25, and the total in the header stays honest, so nothing looks wrong. For an LLM agent consuming the output, a truncated search reads as "no more matches" and becomes a wrong conclusion rather than a smaller one.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ KuSh
❌ seattled23
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[rtk-release-bot]

Automatic message from CI checks : It seems like this branch is targeting the wrong branch, any contribution should target develop branch.

See CONTRIBUTING.md for details.

[HetCreep]

This PR matches what an independent audit of v0.44.2 (700bdde) found, including the #[serde(default)] root cause — the diagnosis in the PR body is correct and the regression test is the right shape. Three things that look like they fall just outside its scope.

Provenance: AI-assisted source audit, human-directed. The deserialization behaviour below was reproduced by building a replica of these exact struct attributes against serde 1 + toml 0.8; the grep counts are from 700bdde.

1. Three sibling structs have the same defect, and the PR only fixes LimitsConfig

At 700bdde, four config structs derive Deserialize with neither Default nor #[serde(default)]:

struct	line	has Default?	#[serde(default)]?
TrackingConfig	config.rs:56-57	no	no
DisplayConfig	config.rs:74-75	no	no
FilterConfig	config.rs:91-92	no	no
LimitsConfig	config.rs:122-123	no	fixed by this PR

(Config, HooksConfig and TelemetryConfig all derive Default, which is why they behave.)

So the failure mode this PR describes — "a config that sets only one field fails to deserialize, which fails the WHOLE Config::load()" — still applies to [tracking], [display] and [filters] after it lands. Reproduced on the replica:

[tracking]
enabled = false          -> TOML parse error

[display]
colors = false           -> TOML parse error

Adding #[serde(default)] to those three as well would make the fix uniform, and the existing regression test generalises to them directly.

2. Six more keys are still declared, serialized, and never read

grep_max_results was the one this PR wires up. Grepping src/ at 700bdde, excluding config.rs itself, these return zero hits:

• tracking.history_days
• display.max_width
• filters.ignore_dirs
• filters.ignore_files
• limits.status_max_files
• limits.status_max_untracked

Since Config::save() and rtk config serialize every field, the written config file advertises these as working settings. (I checked colors, emoji and enabled too — those do appear elsewhere in src/, so I am not claiming them.) Also worth a look: src/cmds/system/README.md:8 states that search.rs reads grep_max_results, which is what this PR is making true — the doc was ahead of the code.

3. An unknown key is still accepted silently

The inverse of the partial-section problem, and untouched by this PR:

Correction (2026-08-06): the example I originally gave here was wrong, and I have replaced it. I wrote that histroy_days = 7 "parses fine, silently ignored". It does not — re-running the replica, a lone misspelled key yields Err: missing field history_days, because the correctly-spelled field is then absent and there is no serde(default) to supply it. My claim that a misspelled key produces silence was false for the current code. What is actually true is narrower, and points the other way:

no serde(default) -- the shape shipping today
  all fields present + unknown key   -> Ok   (unknown key silently ignored)
  partial section + unknown key      -> Err  missing field history_days
  misspelled key only                -> Err  missing field history_days

WITH serde(default) -- what #1483 / #1544 would make them
  all fields present + unknown key   -> Ok   (unknown key silently ignored)
  misspelled key only                -> Ok   history_days silently = 0

So unknown keys are ignored today only when every declared field is present. The part worth acting on is the second block: once serde(default) lands, a misspelled key stops erroring and silently reverts the real setting to its default — a silent-misconfiguration failure mode that does not exist today. No struct carries deny_unknown_fields; adding it alongside serde(default) would close that regression before it ships, and a warning on unrecognised keys would get most of the benefit if outright rejection is too strict for forward compatibility.

None of this is a blocker for the PR as written; it is scoped and correct. Posting so the remaining three structs and the six keys are on the record somewhere, since they will look fixed once [limits] starts working.

[HetCreep]

For the record, since this closed without a technical objection: the diagnosis here is still correct at develop HEAD today.

src/core/config.rs
  TrackingConfig  :57   #[derive(Debug, Serialize, Deserialize)]  — no Default, no serde(default)
  DisplayConfig   :75   same
  FilterConfig    :92   same
  LimitsConfig   :123   same

grep_max_results still appears only in src/core/config.rs and two READMEs — no code reads it — so the [limits] behaviour this PR described is unchanged.

The blockers looked procedural rather than technical: the CI bot flagged on day one that this targets master when contributions go to develop, and the CLA shows 1 of 2 committers signed. If you do pick it back up, worth coordinating with #1483, which already targets develop and adds struct-level #[serde(default)] to all five sub-configs — it has been open since April and covers the partial-section half of this. #1482 is the tracking issue for that behaviour.

Provenance: AI-assisted source audit, human-directed. The line numbers above were read from develop HEAD via the API today; the deserialization behaviour was previously reproduced on a replica of these struct attributes, not on an rtk build.