[GH-ISSUE #7401] [Bug] rea setup removes group-read permission from an existing Codex configuration #4406

New issue

Closed

opened 2026-10-31 00:49:33 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:49:33 +00:00

Owner

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

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

Refreshing a Codex registration with rea setup --client codex --skill=false --yes --json changed the existing config.toml from mode 0640 to 0600. Setup exited 0 and returned status: "ready" with appliedActions: ["configured_codex"]. Its plan said it would preserve unrelated configuration and did not disclose a permission change. The backup retained 0640, and unrelated TOML text remained intact.

Reproduction

Use the built baseline checkout as a sibling directory named rea, and start in an empty working directory. Put Node 24.22.1 on PATH. Create this local fixture:

mkdir -p home/.codex
cat > home/.codex/config.toml <<'TOML'
model = "local-placeholder"
# retain this comment
[mcp_servers.rea]
command = "node"
args = ["x"]
startup_timeout_sec = 0
TOML
chmod 640 home/.codex/config.toml
stat -f '%Sp' home/.codex/config.toml

Run setup with HOME redirected to the fixture and inspect its result and permissions:

HOME="$PWD/home" env -u CODEX_HOME -u XDG_CONFIG_HOME -u DSH_HOME node ../rea/scripts/rea.mjs setup --client codex --skill=false --yes --json > setup.json
node -e 'const r=require("./setup.json"); console.log(JSON.stringify({status:r.status,appliedActions:r.appliedActions}))'
stat -f '%Sp' home/.codex/config.toml
stat -f '%Sp' home/.codex/config.toml.rea.backup

Restore the permission and repeat the now-aligned setup:

chmod 640 home/.codex/config.toml
HOME="$PWD/home" env -u CODEX_HOME -u XDG_CONFIG_HOME -u DSH_HOME node ../rea/scripts/rea.mjs setup --client codex --skill=false --yes --json > aligned.json
node -e 'const r=require("./aligned.json"); console.log(JSON.stringify({status:r.status,appliedActions:r.appliedActions}))'
stat -f '%Sp' home/.codex/config.toml

Observed output, in the order above:

-rw-r-----
{"status":"ready","appliedActions":["configured_codex"]}
-rw-------
-rw-r-----
{"status":"ready","appliedActions":[]}
-rw-r-----

The permission loss reproduced in 3/3 fresh fixtures. Each aligned rerun retained the restored 0640 mode. The zero startup timeout makes the registration require repair. These commands use macOS stat; other platforms were not tested.

Expected behavior

Retain the existing configuration's permissions when refreshing its REA entry. AGENTS.md, “Product and Authority,” says: “Configuration changes must be additive and idempotent, with backups.” It also says: “Preserve caller-selected inputs and local evidence, including output, URLs, paths, digests, and metadata.” Silently removing a caller-selected group-read permission conflicts with those rules. docs/installation.md, “Review setup changes,” tells callers to review the plan's exact paths and changes; this plan does not identify a mode change. The mode should remain 0640 after the registration refresh, as it does on the aligned control.

Impact and scope

The observed change removes the group-read bit from an existing local configuration after a successful setup. No separate group-only reader was run, so downstream access failures remain untested. The behavior was consistent across three Codex fixtures on macOS arm64; other clients, modes, ACLs, and operating systems remain untested. Restoring 0640 with chmod worked, and a subsequent aligned setup kept it. The backup retained the original mode and bytes.

REA version

6.8.0 (source commit a905a71e31)

Runtime and platform

Node 24.22.1; macOS 27.0.1 arm64

Target and artifact context

Not applicable; synthetic local Codex TOML configuration with no credentials or analysis target.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Observed through the public CLI: setup exited 0 with empty stderr and changed -rw-r----- to -rw-------; its backup remained -rw-r-----. The plan detail began Add the REA MCP registration for Codex; preserve unrelated configuration. The unrelated model line and comment survived the rewrite. After chmod 640, the repeated command returned appliedActions: [] and retained -rw-r-----.

Source-only (not executed as an isolated source test): src/application/SetupClientConfiguration.ts:348-354 passes an explicit 0o600 to the configuration publisher. src/application/ClientConfigurationPublication.ts:250 applies the explicit mode before considering the existing input mode. The prebuilt runtime used by the CLI contains the same override. The checkout was clean after all runs.

Typed outcome or recovery expected

A successful refresh should keep mode 0640. If preserving the existing attributes fails, report the preservation operation and recovery guidance rather than silently substituting another mode.

Analysis or suspected cause

Source-only (not executed as a patch): setup's explicit 0o600 overrides the shared publisher's existing-file mode fallback. The early aligned-registration return explains why the control retains 0640. Omitting or restricting the override to new files appears consistent with the publisher's existing fallback, but no fix was implemented or tested.

Additional context

Related but distinct: https://github.com/morluto/rea/issues/6430 is closed after improving diagnostics for ownership/mode preservation failures. This reproduction succeeds while silently changing the mode, and it still reproduces on the stated baseline containing that diagnostic fix. The live npm registry reported 6.8.0 as the latest published version during verification.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7401 ### 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 Refreshing a Codex registration with `rea setup --client codex --skill=false --yes --json` changed the existing `config.toml` from mode `0640` to `0600`. Setup exited 0 and returned `status: "ready"` with `appliedActions: ["configured_codex"]`. Its plan said it would preserve unrelated configuration and did not disclose a permission change. The backup retained `0640`, and unrelated TOML text remained intact. ### Reproduction 1. Use the built baseline checkout as a sibling directory named `rea`, and start in an empty working directory. Put Node 24.22.1 on PATH. Create this local fixture: ```sh mkdir -p home/.codex cat > home/.codex/config.toml <<'TOML' model = "local-placeholder" # retain this comment [mcp_servers.rea] command = "node" args = ["x"] startup_timeout_sec = 0 TOML chmod 640 home/.codex/config.toml stat -f '%Sp' home/.codex/config.toml ``` 2. Run setup with HOME redirected to the fixture and inspect its result and permissions: ```sh HOME="$PWD/home" env -u CODEX_HOME -u XDG_CONFIG_HOME -u DSH_HOME node ../rea/scripts/rea.mjs setup --client codex --skill=false --yes --json > setup.json node -e 'const r=require("./setup.json"); console.log(JSON.stringify({status:r.status,appliedActions:r.appliedActions}))' stat -f '%Sp' home/.codex/config.toml stat -f '%Sp' home/.codex/config.toml.rea.backup ``` 3. Restore the permission and repeat the now-aligned setup: ```sh chmod 640 home/.codex/config.toml HOME="$PWD/home" env -u CODEX_HOME -u XDG_CONFIG_HOME -u DSH_HOME node ../rea/scripts/rea.mjs setup --client codex --skill=false --yes --json > aligned.json node -e 'const r=require("./aligned.json"); console.log(JSON.stringify({status:r.status,appliedActions:r.appliedActions}))' stat -f '%Sp' home/.codex/config.toml ``` Observed output, in the order above: ```text -rw-r----- {"status":"ready","appliedActions":["configured_codex"]} -rw------- -rw-r----- {"status":"ready","appliedActions":[]} -rw-r----- ``` The permission loss reproduced in 3/3 fresh fixtures. Each aligned rerun retained the restored `0640` mode. The zero startup timeout makes the registration require repair. These commands use macOS `stat`; other platforms were not tested. ### Expected behavior Retain the existing configuration's permissions when refreshing its REA entry. `AGENTS.md`, “Product and Authority,” says: “Configuration changes must be additive and idempotent, with backups.” It also says: “Preserve caller-selected inputs and local evidence, including output, URLs, paths, digests, and metadata.” Silently removing a caller-selected group-read permission conflicts with those rules. `docs/installation.md`, “Review setup changes,” tells callers to review the plan's exact paths and changes; this plan does not identify a mode change. The mode should remain `0640` after the registration refresh, as it does on the aligned control. ### Impact and scope The observed change removes the group-read bit from an existing local configuration after a successful setup. No separate group-only reader was run, so downstream access failures remain untested. The behavior was consistent across three Codex fixtures on macOS arm64; other clients, modes, ACLs, and operating systems remain untested. Restoring `0640` with `chmod` worked, and a subsequent aligned setup kept it. The backup retained the original mode and bytes. ### REA version 6.8.0 (source commit a905a71e31f71457cb21fd056b234f872126974e) ### Runtime and platform Node 24.22.1; macOS 27.0.1 arm64 ### Target and artifact context Not applicable; synthetic local Codex TOML configuration with no credentials or analysis target. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Observed through the public CLI: setup exited 0 with empty stderr and changed `-rw-r-----` to `-rw-------`; its backup remained `-rw-r-----`. The plan detail began `Add the REA MCP registration for Codex; preserve unrelated configuration.` The unrelated `model` line and comment survived the rewrite. After `chmod 640`, the repeated command returned `appliedActions: []` and retained `-rw-r-----`. Source-only (not executed as an isolated source test): `src/application/SetupClientConfiguration.ts:348-354` passes an explicit `0o600` to the configuration publisher. `src/application/ClientConfigurationPublication.ts:250` applies the explicit mode before considering the existing input mode. The prebuilt runtime used by the CLI contains the same override. The checkout was clean after all runs. ### Typed outcome or recovery expected A successful refresh should keep mode `0640`. If preserving the existing attributes fails, report the preservation operation and recovery guidance rather than silently substituting another mode. ### Analysis or suspected cause Source-only (not executed as a patch): setup's explicit `0o600` overrides the shared publisher's existing-file mode fallback. The early aligned-registration return explains why the control retains `0640`. Omitting or restricting the override to new files appears consistent with the publisher's existing fallback, but no fix was implemented or tested. ### Additional context Related but distinct: https://github.com/morluto/rea/issues/6430 is closed after improving diagnostics for ownership/mode preservation failures. This reproduction succeeds while silently changing the mode, and it still reproduces on the stated baseline containing that diagnostic fix. The live npm registry reported `6.8.0` as the latest published version during verification.

bsakaguchi closed this issue

2026-10-31 00:49:33 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:46 +00:00

[PR #4406] [MERGED] fix(browser): preserve cleanup failure diagnostics #6217