Skip to content

fix(config): comment out default max_steps/planner_max_steps in rendered project config#4228

Merged
esengine merged 1 commit into
esengine:main-v2from
ashishexee:fix/4166-planner-max-steps-override
Jun 15, 2026
Merged

fix(config): comment out default max_steps/planner_max_steps in rendered project config#4228
esengine merged 1 commit into
esengine:main-v2from
ashishexee:fix/4166-planner-max-steps-override

Conversation

@ashishexee

Copy link
Copy Markdown
Contributor

Fixes #4166

Problem

When a user sets planner_max_steps = 0 in global config (e.g. via Desktop Settings), the project-level reasonix.toml generated by RenderTOML always writes planner_max_steps = 12 as an explicit value. Since project config has higher priority than global config in LoadForRoot() (flag > ./reasonix.toml > ~/.config/reasonix/config.toml > defaults), the project's 12 silently overrides the user's 0.

The same structural issue affects max_steps, though it is currently harmless since both default and written value are 0.

Root Cause

render.go:167-168 unconditionally wrote explicit values for max_steps and planner_max_steps, even when they equal built-in defaults. This created a project-level override that defeated user global settings.

Fix

Comment out max_steps and planner_max_steps when they equal Default() values — same pattern already used for system_prompt, language, system_prompt_file, etc. in the same function.

Before (always written):

max_steps         = 0   # executor tool-call rounds; 0 = no limit
planner_max_steps = 12  # planner read-only tool-call rounds; 0 = no limit

After (commented out when at defaults):

# max_steps         = 0   # executor tool-call rounds; 0 = no limit
# planner_max_steps = 12  # planner read-only tool-call rounds; 0 = no limit

Non-default values are still written explicitly, so intentional project-level overrides work as before.

Tests

  • TestRenderTOMLDefaultStepsCommentedOut — defaults render as comments in [agent] section
  • TestRenderTOMLNonDefaultStepsWrittenExplicitly — non-defaults render as active TOML
  • TestRenderTOMLDefaultStepsDoNotOverrideGlobalConfig — proves the bug is fixed: project config with commented-out defaults does not override global planner_max_steps=0
  • Updated TestRenderTOMLRoundTrips to use non-default step values (consistent with other fields like language, theme, etc.)

Files Changed

  • internal/config/render.go — conditional comment-out for default step values
  • internal/config/render_test.go — 3 new tests + round-trip test update

…red project config

Fixes esengine#4166

When planner_max_steps=0 is set in global config (e.g. via Desktop Settings),
the project-level reasonix.toml generated by RenderTOML always wrote
planner_max_steps=12 as an explicit value. Since project config has higher
priority than global config in LoadForRoot(), the project's 12 silently
overrides the user's 0.

Comment out max_steps and planner_max_steps when they equal Default() values,
same pattern already used for system_prompt, language, etc.
@github-actions github-actions Bot added v2 Go rewrite (1.x) — main-v2 branch, active development config Configuration & setup (internal/config) labels Jun 13, 2026
@esengine esengine merged commit 4dd6796 into esengine:main-v2 Jun 15, 2026
14 checks passed
@ashishexee ashishexee deleted the fix/4166-planner-max-steps-override branch June 15, 2026 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

config Configuration & setup (internal/config) v2 Go rewrite (1.x) — main-v2 branch, active development

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] planner_max_steps=0 still triggers "paused after 12 tool-call rounds" limit

2 participants