[GH-ISSUE #4856] [Bug] TOML client setup and uninstall fail on valid documents with many preserved lines #3019

New issue

Closed

opened 2026-10-31 00:34:58 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:34:58 +00:00

Owner

Originally created by @xu91102 on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4856

Reproduction on current main

Reproduced on 662fad90723b3e5800962bcf02c8c2db1ea2bff5, macOS arm64, Node 24.18.0, after a normal dependency install and source build. This is a local configuration-editing failure; no agent/model or target program needs to run.

A valid Codex config.toml containing these two settings and 140,000 blank lines between them is only 140,088 bytes:

model = "placeholder-local-control"
# Insert 140,000 empty lines here, without this comment.
[mcp_servers.other]
command = "other-local-control"

With HOME, USERPROFILE, CODEX_HOME, XDG_CONFIG_HOME, and temporary storage all pointing into an owned test directory, run:

rea setup --client codex --skill=false --yes --json

The command successfully reads and plans the valid configuration, but exits 1 with status: needs_human, clients.codex.reason: write, and advice to check file permissions. The original file remains unchanged. Replacing the 140,000 blank lines with four makes the same command succeed (ready, exit 0).

The installed native Codex client's read-only codex mcp list --json accepts the same large original file and lists the unrelated server successfully. No MCP child or model request was started by that control.

The shared path also affects Grok Build: 140,000 ordinary comment lines (420,088-byte valid TOML) reproduce the setup failure, while four comments succeed. With an existing REA registration, uninstall of the large Codex document also exits 1 and stops, retaining the original and its recovery backup.

Producer diagnosis and controls

The production parseClientConfiguration accepts these inputs. Calling the existing public serializer on the same parsed documents produces RangeError: Maximum call stack size exceeded at flushPending in ClientConfigurationDocument.upsertTomlServerSection: kept.push(...pending) turns document lines into function arguments.

Two other appends in that same editor have the same limitation. Independently reproduced on the current-main build:

A valid Grok disabled-server list with many physical lines fails at the disabledLines append (1,260,070-byte input).
A foreign MCP entry containing a valid multiline environment value inside an inline TOML table fails at the replacement-line append (280,071-byte input).

This is an engine argument-count limit rather than invalid TOML, permissions, or a file-size refusal. The original files and backups were preserved in the failed CLI controls; I did not observe configuration loss.

Expected behavior

Edit or remove only REA's registration while preserving unrelated settings, comments, values and ordering, without an accidental function-argument limit on accepted source lines. Keep normal planning/approval, backup, idempotency and refusal behavior.

Duplicate check

I read the actual relevant production diffs of merged #1178 (existing TOML source preservation) and open #1717 (Maki integration). They retain the affected argument-spread appends and do not fix this capacity failure. This is separate from the Hermes home-override path selection in #4841. I have not run those other PR heads.

Windows/Linux, native Grok Build, model execution, failure prevalence and performance improvements are not established by this report.

Local fix and verification update

A focused three-file fix is available on my fork at 949ca789, based on the reproduced main revision above. All three source-line append forms use one ordered scalar append in the existing TOML editor. Parsing, file admission, backup, approval and rollback behavior are unchanged.

Fresh relevant verification passed: 14 files / 229 tests, plus 5 README conformance tests (15 distinct files / 234 passed, 0 skipped); check, docs, test discovery, pack dry-run and the installed-package CLI/official MCP verifier passed. Independent frozen Standards and Spec reviews passed. Real packaged CLI preview/apply/repeat/uninstall also passed for both large Codex and Grok configurations, preserving unrelated content and exact original backups. Native Codex read-only mcp list --json accepted the fixed packaged registration. No native Grok agent, model execution, Windows/Linux or performance qualification is claimed.

This is a fork commit, not an upstream PR, CI result or merge. Upstream PR creation is currently unavailable to this account, so I have not retried it.

Maintainer source adoption (2026-10-17)

The maintainer imported the exact three-file patch from xu91102/rea@949ca78974 as c43bc0bf, preserving hhang as the original author. This issue was closed at 19:38:44Z. No upstream PR was created by this account, and this is not a merge of another contributor's PR. The original local validation above remains bound to our frozen fork commit; it is not a fresh validation claim for later main revisions.

Originally created by @xu91102 on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4856 ## Reproduction on current main Reproduced on `662fad90723b3e5800962bcf02c8c2db1ea2bff5`, macOS arm64, Node 24.18.0, after a normal dependency install and source build. This is a local configuration-editing failure; no agent/model or target program needs to run. A valid Codex `config.toml` containing these two settings and 140,000 blank lines between them is only 140,088 bytes: ```toml model = "placeholder-local-control" # Insert 140,000 empty lines here, without this comment. [mcp_servers.other] command = "other-local-control" ``` With `HOME`, `USERPROFILE`, `CODEX_HOME`, `XDG_CONFIG_HOME`, and temporary storage all pointing into an owned test directory, run: ```sh rea setup --client codex --skill=false --yes --json ``` The command successfully reads and plans the valid configuration, but exits 1 with `status: needs_human`, `clients.codex.reason: write`, and advice to check file permissions. The original file remains unchanged. Replacing the 140,000 blank lines with four makes the same command succeed (`ready`, exit 0). The installed native Codex client's read-only `codex mcp list --json` accepts the same large original file and lists the unrelated server successfully. No MCP child or model request was started by that control. The shared path also affects Grok Build: 140,000 ordinary comment lines (420,088-byte valid TOML) reproduce the setup failure, while four comments succeed. With an existing REA registration, uninstall of the large Codex document also exits 1 and stops, retaining the original and its recovery backup. ## Producer diagnosis and controls The production `parseClientConfiguration` accepts these inputs. Calling the existing public serializer on the same parsed documents produces `RangeError: Maximum call stack size exceeded` at `flushPending` in `ClientConfigurationDocument.upsertTomlServerSection`: `kept.push(...pending)` turns document lines into function arguments. Two other appends in that same editor have the same limitation. Independently reproduced on the current-main build: - A valid Grok disabled-server list with many physical lines fails at the `disabledLines` append (1,260,070-byte input). - A foreign MCP entry containing a valid multiline environment value inside an inline TOML table fails at the replacement-line append (280,071-byte input). This is an engine argument-count limit rather than invalid TOML, permissions, or a file-size refusal. The original files and backups were preserved in the failed CLI controls; I did not observe configuration loss. ## Expected behavior Edit or remove only REA's registration while preserving unrelated settings, comments, values and ordering, without an accidental function-argument limit on accepted source lines. Keep normal planning/approval, backup, idempotency and refusal behavior. ## Duplicate check I read the actual relevant production diffs of merged #1178 (existing TOML source preservation) and open #1717 (Maki integration). They retain the affected argument-spread appends and do not fix this capacity failure. This is separate from the Hermes home-override path selection in #4841. I have not run those other PR heads. Windows/Linux, native Grok Build, model execution, failure prevalence and performance improvements are not established by this report. ## Local fix and verification update A focused three-file fix is available on my fork at [949ca789](https://github.com/xu91102/rea/commit/949ca7897497164592e2e80090c15251833fab34), based on the reproduced main revision above. All three source-line append forms use one ordered scalar append in the existing TOML editor. Parsing, file admission, backup, approval and rollback behavior are unchanged. Fresh relevant verification passed: 14 files / 229 tests, plus 5 README conformance tests (15 distinct files / 234 passed, 0 skipped); check, docs, test discovery, pack dry-run and the installed-package CLI/official MCP verifier passed. Independent frozen Standards and Spec reviews passed. Real packaged CLI preview/apply/repeat/uninstall also passed for both large Codex and Grok configurations, preserving unrelated content and exact original backups. Native Codex read-only `mcp list --json` accepted the fixed packaged registration. No native Grok agent, model execution, Windows/Linux or performance qualification is claimed. This is a fork commit, not an upstream PR, CI result or merge. Upstream PR creation is currently unavailable to this account, so I have not retried it. ### Maintainer source adoption (2026-10-17) The maintainer imported the exact three-file patch from xu91102/rea@949ca7897497164592e2e80090c15251833fab34 as [c43bc0bf](https://github.com/morluto/rea/commit/c43bc0bf66a4e245a0cafa40def0d0207bcbd73c), preserving hhang as the original author. This issue was closed at 19:38:44Z. No upstream PR was created by this account, and this is not a merge of another contributor's PR. The original local validation above remains bound to our frozen fork commit; it is not a fresh validation claim for later main revisions.

bsakaguchi closed this issue

2026-10-31 00:34:59 +00:00

bsakaguchi commented

2026-10-31 00:35:00 +00:00

Author

Owner

@vardhans07 commented on GitHub (Oct 17, 2026):

Please assign to me

@vardhans07 commented on GitHub (Oct 17, 2026): Please assign to me

bsakaguchi referenced this issue

2026-10-31 01:09:32 +00:00

[PR #3521] feat(reverse): add radare2 one-shot commands and analysis sessions #5800