[GH-ISSUE #3206] [Bug] Malformed settings in an untrusted Gemini workspace make setup and doctor fail #1143

Closed
opened 2026-10-15 18:31:27 +00:00 by bsakaguchi · 1 comment
Owner

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

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

With a valid Gemini user registration and malformed .gemini/settings.json in the current untrusted workspace, setup --client gemini_cli --yes --json exits 1 with status: "needs_human", empty appliedActions, and a malformed-workspace-file remediation. doctor --client gemini_cli --json also exits 1 and reports the user registration as invalid for the same reason. The user settings file remained byte-for-byte unchanged across these failures.

Replacing only the workspace input with a well-formed mcp.excluded policy for rea made setup return ready and doctor report an aligned registration, both with exit 0, without adding trust. Explicitly setting GEMINI_CLI_TRUST_WORKSPACE=false still left malformed workspace settings blocking setup. Running the same setup and doctor commands from the isolated home succeeded while the separate workspace file stayed malformed.

Reproduction

Use a clean checkout at 58300885207133422af235e0f2b10658cf958b03 and the supported Node.js toolchain. Run these steps from the checkout root. The install/build commands are prerequisites; the verifier used a prepared installed and built checkout and replayed the CLI sequence below.

  1. Install the locked dependencies:

    npm ci
    
  2. Build the CLI:

    npm run build:cached
    
  3. Create the inputs inline and run setup/doctor with isolated home, XDG and Gemini roots. No trusted-folders file exists, and both system settings paths point to absent files. The sequence also checks well-formed untrusted settings, explicit trust, explicit distrust, and a different working directory.

REPO="$PWD"
REPRO="$(mktemp -d)"
mkdir -p "$REPRO/home/.gemini" "$REPRO/workspace/.gemini"
env -i PATH="$PATH" REPO="$REPO" REPRO="$REPRO" \
  HOME="$REPRO/home" \
  TMPDIR="$REPRO" \
  XDG_CONFIG_HOME="$REPRO/home/.config" \
  XDG_CACHE_HOME="$REPRO/home/.cache" \
  XDG_DATA_HOME="$REPRO/home/.local/share" \
  GEMINI_CLI_HOME="$REPRO/home" \
  GEMINI_CLI_SYSTEM_SETTINGS_PATH="$REPRO/system/settings.json" \
  GEMINI_CLI_SYSTEM_DEFAULTS_PATH="$REPRO/system/defaults.json" \
  GEMINI_CLI_TRUSTED_FOLDERS_PATH="$REPRO/home/.gemini/trustedFolders.json" \
  sh <<'SH'
run_rea() {
  node "$REPO/scripts/rea.mjs" "$@"
  printf 'exit=%s\n' "$?"
}
cat > "$HOME/.gemini/settings.json" <<'JSON'
{"mcpServers":{"rea":{"command":"rea","args":["mcp"]}}}
JSON
cd "$REPRO/workspace"
printf '%s' '{ not json' > .gemini/settings.json
run_rea setup --client gemini_cli --yes --json
run_rea doctor --client gemini_cli --json

printf '%s' '{"mcp":{"excluded":["rea"]}}' > .gemini/settings.json
run_rea setup --client gemini_cli --yes --json
run_rea doctor --client gemini_cli --json

export GEMINI_CLI_TRUST_WORKSPACE=true
run_rea setup --client gemini_cli --yes --json
printf '%s' '{ not json' > .gemini/settings.json
run_rea setup --client gemini_cli --yes --json

export GEMINI_CLI_TRUST_WORKSPACE=false
run_rea setup --client gemini_cli --yes --json
unset GEMINI_CLI_TRUST_WORKSPACE
cd "$HOME"
run_rea setup --client gemini_cli --yes --json
run_rea doctor --client gemini_cli --json
SH
  1. Observe setup/doctor exit codes 1, 1, 0, 0, 1, 1, 1, 0, 0 in order. The first two calls fail on malformed untrusted settings. The well-formed untrusted exclusion succeeds. Both explicitly trusted controls fail for their applicable configuration reasons. Explicit distrust still fails on malformed settings. The final home-directory calls succeed while the separate workspace file remains malformed. Retain the disposable fixture only as long as its output is needed.

Expected behavior

docs/client-configuration.md:192-206 says setup and doctor check Gemini policies from trusted workspace settings and states: "Settings in an untrusted workspace do not participate." A malformed file in that excluded scope should not prevent setup from completing or invalidate a valid user registration. Trusted workspace settings should still participate, including rejecting malformed settings and enforcing an exclusion of rea. Setup should preserve workspace settings and leave trust decisions to the caller, as the same documentation requires.

Impact and scope

This blocks Gemini integration setup and produces a false registration-readiness failure when the current untrusted workspace has malformed settings. Running the same user-level checks outside the affected workspace is a demonstrated workaround that leaves workspace bytes and trust unchanged. No user-file corruption or effective acceptance of untrusted policy was observed. The reproduction covers REA's standalone CLI checks; it does not establish behavior inside a running Gemini client.

REA version

6.4.0 (main at 5830088520)

Runtime and platform

Node.js 24.21.0; macOS arm64. The verifier did not specify the macOS version. HOME and all XDG roots were isolated, and Gemini user, system, defaults and trust-file paths pointed into disposable configuration directories.

Target and artifact context

No binary target or analysis artifact is required. The inputs are a valid Gemini user registration, a separate workspace settings file and absent trust/system settings files. No live Gemini service or analysis engine was invoked.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The verifier recorded these reduced command results:

Untrusted malformed workspace:
  setup: exit 1; status needs_human; appliedActions []
  doctor: exit 1; registration state invalid
  malformed-file detail: Invalid JSON/JSONC at offset 2: InvalidSymbol
Untrusted well-formed exclusion:
  setup: exit 0; status ready
  doctor: exit 0; registration state aligned
Explicitly trusted well-formed exclusion:
  setup: exit 1; Gemini mcp.excluded blocks rea
Explicitly trusted malformed workspace:
  setup: exit 1; status needs_human; registration invalid
Explicitly untrusted malformed workspace:
  setup: exit 1; status needs_human; registration invalid
Home working directory, separate workspace still malformed:
  setup: exit 0; status ready
  doctor: exit 0; registration state aligned

Typed outcome or recovery expected

With the same malformed untrusted fixture, setup should return ready and doctor should report the valid user registration as aligned, with exit 0, without changing the workspace settings or trust. The same result should hold under the explicit false trust override. Keep well-formed untrusted exclusions ignored. Under explicit true trust, the exclusion and malformed settings should still produce their existing failures. These checks distinguish correct trust filtering from ignoring all workspace settings.

Analysis or suspected cause

Source-derived reasoning at the stated baseline: src/application/GeminiClientSettings.ts:146-157 parses the workspace settings and returns a parsing failure before checking workspaceTrusted. src/application/SetupClientConfiguration.ts:443-460 converts that policy-reader failure into an invalid inspection with the error detail. src/application/GeminiClientSettings.ts:66-92 defaults folder trust to enabled and returns untrusted when the trust file is missing. The prepared compiled implementation preserves this ordering, according to the verifier. The observed public CLI runs corroborate the source analysis; the policy reader returns a malformed-file result rather than requiring clientConfigurationDesired to throw.

Additional context

P2 is supported because this is a consequential configuration/readiness failure bounded to particular workspace inputs, with a demonstrated workaround outside the workspace. Granting trust cannot repair malformed JSON and is not the workaround used here.

Originally created by @coygeek on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3206 ### 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 With a valid Gemini user registration and malformed `.gemini/settings.json` in the current untrusted workspace, `setup --client gemini_cli --yes --json` exits 1 with `status: "needs_human"`, empty `appliedActions`, and a malformed-workspace-file remediation. `doctor --client gemini_cli --json` also exits 1 and reports the user registration as `invalid` for the same reason. The user settings file remained byte-for-byte unchanged across these failures. Replacing only the workspace input with a well-formed `mcp.excluded` policy for `rea` made setup return `ready` and doctor report an `aligned` registration, both with exit 0, without adding trust. Explicitly setting `GEMINI_CLI_TRUST_WORKSPACE=false` still left malformed workspace settings blocking setup. Running the same setup and doctor commands from the isolated home succeeded while the separate workspace file stayed malformed. ### Reproduction Use a clean checkout at `58300885207133422af235e0f2b10658cf958b03` and the supported Node.js toolchain. Run these steps from the checkout root. The install/build commands are prerequisites; the verifier used a prepared installed and built checkout and replayed the CLI sequence below. 1. Install the locked dependencies: ```sh npm ci ``` 2. Build the CLI: ```sh npm run build:cached ``` 3. Create the inputs inline and run setup/doctor with isolated home, XDG and Gemini roots. No trusted-folders file exists, and both system settings paths point to absent files. The sequence also checks well-formed untrusted settings, explicit trust, explicit distrust, and a different working directory. ```sh REPO="$PWD" REPRO="$(mktemp -d)" mkdir -p "$REPRO/home/.gemini" "$REPRO/workspace/.gemini" env -i PATH="$PATH" REPO="$REPO" REPRO="$REPRO" \ HOME="$REPRO/home" \ TMPDIR="$REPRO" \ XDG_CONFIG_HOME="$REPRO/home/.config" \ XDG_CACHE_HOME="$REPRO/home/.cache" \ XDG_DATA_HOME="$REPRO/home/.local/share" \ GEMINI_CLI_HOME="$REPRO/home" \ GEMINI_CLI_SYSTEM_SETTINGS_PATH="$REPRO/system/settings.json" \ GEMINI_CLI_SYSTEM_DEFAULTS_PATH="$REPRO/system/defaults.json" \ GEMINI_CLI_TRUSTED_FOLDERS_PATH="$REPRO/home/.gemini/trustedFolders.json" \ sh <<'SH' run_rea() { node "$REPO/scripts/rea.mjs" "$@" printf 'exit=%s\n' "$?" } cat > "$HOME/.gemini/settings.json" <<'JSON' {"mcpServers":{"rea":{"command":"rea","args":["mcp"]}}} JSON cd "$REPRO/workspace" printf '%s' '{ not json' > .gemini/settings.json run_rea setup --client gemini_cli --yes --json run_rea doctor --client gemini_cli --json printf '%s' '{"mcp":{"excluded":["rea"]}}' > .gemini/settings.json run_rea setup --client gemini_cli --yes --json run_rea doctor --client gemini_cli --json export GEMINI_CLI_TRUST_WORKSPACE=true run_rea setup --client gemini_cli --yes --json printf '%s' '{ not json' > .gemini/settings.json run_rea setup --client gemini_cli --yes --json export GEMINI_CLI_TRUST_WORKSPACE=false run_rea setup --client gemini_cli --yes --json unset GEMINI_CLI_TRUST_WORKSPACE cd "$HOME" run_rea setup --client gemini_cli --yes --json run_rea doctor --client gemini_cli --json SH ``` 4. Observe setup/doctor exit codes `1, 1, 0, 0, 1, 1, 1, 0, 0` in order. The first two calls fail on malformed untrusted settings. The well-formed untrusted exclusion succeeds. Both explicitly trusted controls fail for their applicable configuration reasons. Explicit distrust still fails on malformed settings. The final home-directory calls succeed while the separate workspace file remains malformed. Retain the disposable fixture only as long as its output is needed. ### Expected behavior `docs/client-configuration.md:192-206` says setup and doctor check Gemini policies from trusted workspace settings and states: "Settings in an untrusted workspace do not participate." A malformed file in that excluded scope should not prevent setup from completing or invalidate a valid user registration. Trusted workspace settings should still participate, including rejecting malformed settings and enforcing an exclusion of `rea`. Setup should preserve workspace settings and leave trust decisions to the caller, as the same documentation requires. ### Impact and scope This blocks Gemini integration setup and produces a false registration-readiness failure when the current untrusted workspace has malformed settings. Running the same user-level checks outside the affected workspace is a demonstrated workaround that leaves workspace bytes and trust unchanged. No user-file corruption or effective acceptance of untrusted policy was observed. The reproduction covers REA's standalone CLI checks; it does not establish behavior inside a running Gemini client. ### REA version 6.4.0 (main at 58300885207133422af235e0f2b10658cf958b03) ### Runtime and platform Node.js 24.21.0; macOS arm64. The verifier did not specify the macOS version. HOME and all XDG roots were isolated, and Gemini user, system, defaults and trust-file paths pointed into disposable configuration directories. ### Target and artifact context No binary target or analysis artifact is required. The inputs are a valid Gemini user registration, a separate workspace settings file and absent trust/system settings files. No live Gemini service or analysis engine was invoked. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The verifier recorded these reduced command results: ```text Untrusted malformed workspace: setup: exit 1; status needs_human; appliedActions [] doctor: exit 1; registration state invalid malformed-file detail: Invalid JSON/JSONC at offset 2: InvalidSymbol Untrusted well-formed exclusion: setup: exit 0; status ready doctor: exit 0; registration state aligned Explicitly trusted well-formed exclusion: setup: exit 1; Gemini mcp.excluded blocks rea Explicitly trusted malformed workspace: setup: exit 1; status needs_human; registration invalid Explicitly untrusted malformed workspace: setup: exit 1; status needs_human; registration invalid Home working directory, separate workspace still malformed: setup: exit 0; status ready doctor: exit 0; registration state aligned ``` ### Typed outcome or recovery expected With the same malformed untrusted fixture, setup should return `ready` and doctor should report the valid user registration as `aligned`, with exit 0, without changing the workspace settings or trust. The same result should hold under the explicit false trust override. Keep well-formed untrusted exclusions ignored. Under explicit true trust, the exclusion and malformed settings should still produce their existing failures. These checks distinguish correct trust filtering from ignoring all workspace settings. ### Analysis or suspected cause Source-derived reasoning at the stated baseline: `src/application/GeminiClientSettings.ts:146-157` parses the workspace settings and returns a parsing failure before checking `workspaceTrusted`. `src/application/SetupClientConfiguration.ts:443-460` converts that policy-reader failure into an invalid inspection with the error detail. `src/application/GeminiClientSettings.ts:66-92` defaults folder trust to enabled and returns untrusted when the trust file is missing. The prepared compiled implementation preserves this ordering, according to the verifier. The observed public CLI runs corroborate the source analysis; the policy reader returns a malformed-file result rather than requiring `clientConfigurationDesired` to throw. ### Additional context P2 is supported because this is a consequential configuration/readiness failure bounded to particular workspace inputs, with a demonstrated workaround outside the workspace. Granting trust cannot repair malformed JSON and is not the workaround used here.
bsakaguchi 2026-10-15 18:31:27 +00:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@morluto commented on GitHub (Oct 14, 2026):

Resolved on main by aade9bbcb.

Workspace trust is evaluated before Gemini workspace settings are parsed; malformed untrusted settings are preserved and ignored, while trusted malformed settings remain rejected.

Rechecked on main b8510ee00 in the current focused run: 20 test files passed, 225 tests passed and one platform-dependent test skipped. Relevant regression coverage: tests/acceptance/setup/geminiWorkspaceTrust.test.ts.

<!-- gh-comment-id:6174976527 --> @morluto commented on GitHub (Oct 14, 2026): Resolved on main by aade9bbcb. Workspace trust is evaluated before Gemini workspace settings are parsed; malformed untrusted settings are preserved and ignored, while trusted malformed settings remain rejected. Rechecked on main b8510ee00 in the current focused run: 20 test files passed, 225 tests passed and one platform-dependent test skipped. Relevant regression coverage: tests/acceptance/setup/geminiWorkspaceTrust.test.ts.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#1143
No description provided.