morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #3863] [Bug] rea setup deletes Codex per-tool approval settings when refreshing the registration #1484

New issue

Closed

opened 2026-10-16 21:06:03 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-16 21:06:03 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3863

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

rea setup --client codex rewrites the whole [mcp_servers.rea] entry and drops any [mcp_servers.rea.tools.<name>] tables, such as approval_mode="approve". Setup reports success and its plan does not mention the removal; the original settings survive only in config.toml.rea.backup.

The dry run exits 0 with status: "planned" and one configure_client:codex update action that does not mention the tools table. The apply exits 0 with status: "ready" and appliedActions: ["configured_codex"]. The rewritten file keeps the launcher and both timeouts but contains no tools table and no approval_mode. The backup matches the original fixture byte for byte.

Reproduction

Run from the root of a built source checkout. The helper isolates every client configuration directory in a disposable home; npm_command=exec and the npm user agent make REA keep the pinned npx launcher without invoking npm. --skill=false keeps the run limited to the client registration.

REA_CHECKOUT="$PWD"
trial="$(mktemp -d)"
mkdir -p "$trial/.codex"
cat > "$trial/.codex/config.toml" <<'TOML'
[mcp_servers.rea]
command="npx"
args=["-y", "rea-agents@6.5.0", "mcp"]
startup_timeout_sec=30
tool_timeout_sec=600

[mcp_servers.rea.tools.binary_session]
approval_mode="approve"
TOML
run_rea() {
  env -i PATH="$(dirname "$(command -v node)"):/usr/bin:/bin:/usr/sbin:/sbin" \
    HOME="$trial" XDG_CONFIG_HOME="$trial/.config" \
    CODEX_HOME="$trial/.codex" CLAUDE_CONFIG_DIR="$trial/.claude" \
    npm_config_prefix="$trial/.npm-global" \
    npm_command=exec npm_config_user_agent=npm/12.0.0 \
    node "$REA_CHECKOUT/scripts/rea.mjs" "$@"
}
cd "$trial"
run_rea setup --client codex --skill=false --dry-run --json
run_rea setup --client codex --skill=false --yes --json
cat "$trial/.codex/config.toml"
cmp "$trial/.codex/config.toml.rea.backup" <(cat <<'TOML'
[mcp_servers.rea]
command="npx"
args=["-y", "rea-agents@6.5.0", "mcp"]
startup_timeout_sec=30
tool_timeout_sec=600

[mcp_servers.rea.tools.binary_session]
approval_mode="approve"
TOML
) && echo backup-equal

Expected behavior

Setup updates REA's launcher and environment and keeps the caller's per-tool table. AGENTS.md:11 requires configuration changes to be additive, AGENTS.md:13 requires preserving caller-selected inputs and metadata, and docs/installation.md:59-60 states that agent configuration writes preserve unrelated entries. REA's own Codex verifier uses this setting shape at scripts/verify-agent-experience.mjs:495-497. If setup must remove a field, its plan should say so before applying.

Impact and scope

Codex users who customize REA tool approval settings silently lose them on every setup refresh, and the change persists in their client configuration.

Workaround: available. The original configuration is preserved in config.toml.rea.backup (verified byte-equal), so users can reapply the tools table after setup.

Reporter's impact estimate: P2 (supported).

REA version

6.5.0, built from source at main commit 034342ba28 (latest npm release is 6.5.0)

Runtime and platform

Node.js v26.10.0; macOS 27.0.1 arm64

Target and artifact context

Codex MCP client config.toml registration

Interface

CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

Expected source: AGENTS.md:11, AGENTS.md:13, and docs/installation.md:59-60 (writes preserve unrelated entries)
Failure source: observed rea setup --client codex --skill=false --yes --json result and the rewritten config.toml; replacement at src/application/SetupClientConfiguration.ts:735-764 and :267-272
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Apply result fields:

{"status":"ready","appliedActions":["configured_codex"]}

REA entry in the rewritten config.toml (it also gained a detected Hopper launcher in an env table; no Hopper installation was requested or performed):

[mcp_servers.rea]
command = "npx"
args = [ "-y", "rea-agents@6.5.0", "mcp" ]
startup_timeout_sec = 30
tool_timeout_sec = 600

A byte comparison of config.toml.rea.backup with the complete original fixture found them equal. The effect of the lost policy on a later Codex session was not run.

Source-derived analysis: clientConfigurationDesired builds a fresh entry at src/application/SetupClientConfiguration.ts:735-739 and, for Codex, carries over only startup_timeout_sec and tool_timeout_sec from the previous entry at lines 750-764. persistClientConfiguration then replaces the entire rea server entry at lines 267-272. Other caller fields on the Codex entry are likely dropped the same way; only the per-tool table was reproduced.

Typed outcome or recovery expected

Setup should keep the caller's [mcp_servers.rea.tools.*] tables while refreshing the launcher, or its plan should name any field it removes before applying.

Restoration check:

On the same fixture, the rewritten config.toml currently lacks [mcp_servers.rea.tools.binary_session]; after a fix it should still contain that table with approval_mode="approve" alongside the refreshed launcher. As a control, the two timeout values are already preserved today and should remain so.

Analysis or suspected cause

Source-derived: clientConfigurationDesired builds a fresh entry at src/application/SetupClientConfiguration.ts:735-739 and keeps only the two Codex timeouts at lines 750-764; persistClientConfiguration replaces the whole rea entry at lines 267-272.

Additional context

rea doctor --client codex currently reports registrations with this table as invalid and recommends rea setup, which leads users into this deletion; that diagnostic is reported separately. Closed #1163 covers TOML comment loss only, and closed #1606 covers environment overrides, which this fixture retained. No open issue reports this failure.

This report came from AI-assisted source review with local reproduction where stated above; the evidence labels distinguish observed runs from source-only reasoning.

Originally created by @coygeek on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3863 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior `rea setup --client codex` rewrites the whole `[mcp_servers.rea]` entry and drops any `[mcp_servers.rea.tools.<name>]` tables, such as `approval_mode="approve"`. Setup reports success and its plan does not mention the removal; the original settings survive only in `config.toml.rea.backup`. The dry run exits 0 with `status: "planned"` and one `configure_client:codex` update action that does not mention the tools table. The apply exits 0 with `status: "ready"` and `appliedActions: ["configured_codex"]`. The rewritten file keeps the launcher and both timeouts but contains no `tools` table and no `approval_mode`. The backup matches the original fixture byte for byte. ### Reproduction Run from the root of a built source checkout. The helper isolates every client configuration directory in a disposable home; `npm_command=exec` and the npm user agent make REA keep the pinned `npx` launcher without invoking npm. `--skill=false` keeps the run limited to the client registration. ```sh REA_CHECKOUT="$PWD" trial="$(mktemp -d)" mkdir -p "$trial/.codex" cat > "$trial/.codex/config.toml" <<'TOML' [mcp_servers.rea] command="npx" args=["-y", "rea-agents@6.5.0", "mcp"] startup_timeout_sec=30 tool_timeout_sec=600 [mcp_servers.rea.tools.binary_session] approval_mode="approve" TOML run_rea() { env -i PATH="$(dirname "$(command -v node)"):/usr/bin:/bin:/usr/sbin:/sbin" \ HOME="$trial" XDG_CONFIG_HOME="$trial/.config" \ CODEX_HOME="$trial/.codex" CLAUDE_CONFIG_DIR="$trial/.claude" \ npm_config_prefix="$trial/.npm-global" \ npm_command=exec npm_config_user_agent=npm/12.0.0 \ node "$REA_CHECKOUT/scripts/rea.mjs" "$@" } cd "$trial" run_rea setup --client codex --skill=false --dry-run --json run_rea setup --client codex --skill=false --yes --json cat "$trial/.codex/config.toml" cmp "$trial/.codex/config.toml.rea.backup" <(cat <<'TOML' [mcp_servers.rea] command="npx" args=["-y", "rea-agents@6.5.0", "mcp"] startup_timeout_sec=30 tool_timeout_sec=600 [mcp_servers.rea.tools.binary_session] approval_mode="approve" TOML ) && echo backup-equal ``` ### Expected behavior Setup updates REA's launcher and environment and keeps the caller's per-tool table. `AGENTS.md:11` requires configuration changes to be additive, `AGENTS.md:13` requires preserving caller-selected inputs and metadata, and `docs/installation.md:59-60` states that agent configuration writes preserve unrelated entries. REA's own Codex verifier uses this setting shape at `scripts/verify-agent-experience.mjs:495-497`. If setup must remove a field, its plan should say so before applying. ### Impact and scope Codex users who customize REA tool approval settings silently lose them on every setup refresh, and the change persists in their client configuration. Workaround: available. The original configuration is preserved in `config.toml.rea.backup` (verified byte-equal), so users can reapply the tools table after setup. Reporter's impact estimate: P2 (supported). ### REA version 6.5.0, built from source at main commit 034342ba28c8e56c3746be92b78aa7299afa02bd (latest npm release is 6.5.0) ### Runtime and platform Node.js v26.10.0; macOS 27.0.1 arm64 ### Target and artifact context Codex MCP client config.toml registration ### Interface CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence - Expected source: `AGENTS.md:11`, `AGENTS.md:13`, and `docs/installation.md:59-60` (writes preserve unrelated entries) - Failure source: observed `rea setup --client codex --skill=false --yes --json` result and the rewritten `config.toml`; replacement at `src/application/SetupClientConfiguration.ts:735-764` and `:267-272` - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Apply result fields: ```json {"status":"ready","appliedActions":["configured_codex"]} ``` REA entry in the rewritten `config.toml` (it also gained a detected Hopper launcher in an `env` table; no Hopper installation was requested or performed): ```toml [mcp_servers.rea] command = "npx" args = [ "-y", "rea-agents@6.5.0", "mcp" ] startup_timeout_sec = 30 tool_timeout_sec = 600 ``` A byte comparison of `config.toml.rea.backup` with the complete original fixture found them equal. The effect of the lost policy on a later Codex session was not run. Source-derived analysis: `clientConfigurationDesired` builds a fresh entry at `src/application/SetupClientConfiguration.ts:735-739` and, for Codex, carries over only `startup_timeout_sec` and `tool_timeout_sec` from the previous entry at lines 750-764. `persistClientConfiguration` then replaces the entire `rea` server entry at lines 267-272. Other caller fields on the Codex entry are likely dropped the same way; only the per-tool table was reproduced. ### Typed outcome or recovery expected Setup should keep the caller's [mcp_servers.rea.tools.*] tables while refreshing the launcher, or its plan should name any field it removes before applying. Restoration check: On the same fixture, the rewritten `config.toml` currently lacks `[mcp_servers.rea.tools.binary_session]`; after a fix it should still contain that table with `approval_mode="approve"` alongside the refreshed launcher. As a control, the two timeout values are already preserved today and should remain so. ### Analysis or suspected cause Source-derived: clientConfigurationDesired builds a fresh entry at src/application/SetupClientConfiguration.ts:735-739 and keeps only the two Codex timeouts at lines 750-764; persistClientConfiguration replaces the whole rea entry at lines 267-272. ### Additional context `rea doctor --client codex` currently reports registrations with this table as `invalid` and recommends `rea setup`, which leads users into this deletion; that diagnostic is reported separately. Closed #1163 covers TOML comment loss only, and closed #1606 covers environment overrides, which this fixture retained. No open issue reports this failure. This report came from AI-assisted source review with local reproduction where stated above; the evidence labels distinguish observed runs from source-only reasoning.

bsakaguchi commented

2026-10-16 21:06:04 +00:00

Author

Owner

@yankikucuk commented on GitHub (Oct 15, 2026):

Working on this together with #3862. Reproduced through rea setup --client codex --skill=false --yes --json: the refreshed entry lost [mcp_servers.rea.tools.binary_session]. The Codex desired entry now carries the previous tools table over next to the retained timeouts; an aligned registration is left untouched and a stale launcher is rewritten with the table intact. Draft PR follows shortly.

@yankikucuk commented on GitHub (Oct 15, 2026): Working on this together with #3862. Reproduced through `rea setup --client codex --skill=false --yes --json`: the refreshed entry lost `[mcp_servers.rea.tools.binary_session]`. The Codex desired entry now carries the previous `tools` table over next to the retained timeouts; an aligned registration is left untouched and a stale launcher is rewritten with the table intact. Draft PR follows shortly.

bsakaguchi commented

2026-10-16 21:06:04 +00:00

Author

Owner

@SoGeRiEn commented on GitHub (Oct 15, 2026):

Fixed on fix/reliability-pack-20261015 at 12309d27. Setup now preserves Codex per-tool approval tables.

@SoGeRiEn commented on GitHub (Oct 15, 2026): Fixed on `fix/reliability-pack-20261015` at 12309d27. Setup now preserves Codex per-tool approval tables.

bsakaguchi referenced this issue

2026-10-16 21:07:46 +00:00

[GH-ISSUE #4025] [Bug] Gemini-backed clients reject the whole tool catalog: advertised schemas emit non-string const values (boolean enum MUST be TYPE_STRING) #1601

bsakaguchi referenced this issue

2026-10-17 21:11:59 +00:00

[PR #1514] [MERGED] feat(mcp): compact input schema profile for size-capped providers (kimi-cli/Moonshot) #2934

bsakaguchi referenced this issue

2026-10-31 00:29:44 +00:00

[GH-ISSUE #2512] [Feature] Opt-in output-schema-light tools/list advertisement for frame-capped MCP clients #831

bsakaguchi referenced this issue

2026-10-31 00:29:52 +00:00

[GH-ISSUE #2999] [Bug] WorkBuddy/CodeBuddy-backed gateway rejects the whole tool catalog with HTTP 400 code 11133 on the default profile; REA_MCP_INPUT_SCHEMA_PROFILE=compact fixes it #1050

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

@monsterlag commented on GitHub (Oct 19, 2026):

The same happens with the server-level default_tools_approval_mode key, not only per-tool tables. That was reproduced on 6.7.0 (npm global, macOS 27 arm64). rea setup --client codex refreshes the entry and drops default_tools_approval_mode = "approve" from [mcp_servers.rea]. The plan doesn't mention the removal, and the apply reports success.

trial="$(mktemp -d)"; mkdir -p "$trial/.codex"
cat > "$trial/.codex/config.toml" <<'TOML'
[mcp_servers.rea]
command = "/opt/homebrew/bin/rea"
args = ["mcp"]
default_tools_approval_mode = "approve"
startup_timeout_sec = 30
tool_timeout_sec = 450
TOML
cp "$trial/.codex/config.toml" "$trial/before.toml"
(cd "$trial" && HOME="$trial" CODEX_HOME="$trial/.codex" rea setup --client codex --skill=false --yes >/dev/null)
diff "$trial/before.toml" "$trial/.codex/config.toml"
#   < default_tools_approval_mode = "approve"   (removed)

For unattended use this matters as much as the per-tool tables: without the key, Codex prompts for every REA tool call. So users who rely on it can't let rea setup (or a scheduled updater) refresh the registration, and they hit registration:codex config_drift from rea doctor whenever a release changes the expected entry. On 6.7.0 that happened when tool_timeout_sec = 450 became part of it. It would help if the fix for this issue preserved default_tools_approval_mode (and any other unrecognised server-level keys) alongside the tools table.

@monsterlag commented on GitHub (Oct 19, 2026): The same happens with the **server-level** `default_tools_approval_mode` key, not only per-tool tables. That was reproduced on 6.7.0 (npm global, macOS 27 arm64). `rea setup --client codex` refreshes the entry and drops `default_tools_approval_mode = "approve"` from `[mcp_servers.rea]`. The plan doesn't mention the removal, and the apply reports success. ```sh trial="$(mktemp -d)"; mkdir -p "$trial/.codex" cat > "$trial/.codex/config.toml" <<'TOML' [mcp_servers.rea] command = "/opt/homebrew/bin/rea" args = ["mcp"] default_tools_approval_mode = "approve" startup_timeout_sec = 30 tool_timeout_sec = 450 TOML cp "$trial/.codex/config.toml" "$trial/before.toml" (cd "$trial" && HOME="$trial" CODEX_HOME="$trial/.codex" rea setup --client codex --skill=false --yes >/dev/null) diff "$trial/before.toml" "$trial/.codex/config.toml" # < default_tools_approval_mode = "approve" (removed) ``` For unattended use this matters as much as the per-tool tables: without the key, Codex prompts for every REA tool call. So users who rely on it can't let `rea setup` (or a scheduled updater) refresh the registration, and they hit `registration:codex` config_drift from `rea doctor` whenever a release changes the expected entry. On 6.7.0 that happened when `tool_timeout_sec = 450` became part of it. It would help if the fix for this issue preserved `default_tools_approval_mode` (and any other unrecognised server-level keys) alongside the `tools` table.

bsakaguchi commented

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

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

Setup now passes the previous source-fragment server entry into refreshClientRegistration, which replaces managed connection fields while preserving every other own setting. This retains tools, default_tools_approval_mode (the follow-up comment), future server policy fields and valid explicit timeouts. Policy validation is separate and fails before writing malformed policy.

Implementation: SetupClientConfiguration.ts, ClientRegistration.ts.

The relevant regression checks in codexClientPolicy.test.ts, codexToolPolicySetup.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. Setup now passes the previous source-fragment server entry into refreshClientRegistration, which replaces managed connection fields while preserving every other own setting. This retains tools, default_tools_approval_mode (the follow-up comment), future server policy fields and valid explicit timeouts. Policy validation is separate and fails before writing malformed policy. Implementation: [SetupClientConfiguration.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/application/SetupClientConfiguration.ts#L813), [ClientRegistration.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/application/ClientRegistration.ts#L181). The relevant regression checks in [codexClientPolicy.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/filesystem/codexClientPolicy.test.ts), [codexToolPolicySetup.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/acceptance/setup/codexToolPolicySetup.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 00:37:27 +00:00

[GH-ISSUE #5160] [Bug] Codex + kimi-k3: older REA schemas trigger misleading recursion errors; recovery guidance missing #3170

bsakaguchi referenced this issue

2026-10-31 00:55:29 +00:00

[PR #1804] [CLOSED] feat(setup): register Kimi Code client with compact schema profile #4826

bsakaguchi referenced this issue

2026-10-31 01:14:23 +00:00

[PR #4828] [CLOSED] fix(claude): prefer compact profiles for oversized tool schemas #6430