[alecuba16]

Makes the bash destructive-command gate a config option with a /settings toggle, default on so behavior does not change for existing users. Config roundtrips through config.toml, env overrides included, and the gate reads the toggle live instead of caching it at startup.

Closes #897.

[greptile-apps]

Confidence Score: 4/5

[Critical impact] The PR adds a user-controlled switch to a gate that protects local files from destructive bash commands.

The PR should not merge until the settings tests stop overwriting real configuration.

Findings

1.  Tests overwrite real settings ▶
2.  Settings show the wrong state ▶
3.  Config and bash disagree ▶
4.  Config example uses wrong section ▶
5.  SSH toggle instructions fail ▶

Fix with agent prompt

### Issue 1
crates/jcode-tui/src/tui/app/commands_tests.rs:457-464
If `JCODE_HOME` is unset, running a settings test by itself rewrites the developer's real `~/.jcode/config.toml`: `with_clean_config` loads and saves before `create_test_app` installs the temporary test home. Executing the existing settings-display test against isolated home directories confirmed that it changes a saved `risk_gate_enabled = false` to `true` and replaces malformed configuration with defaults, even though the test passes.

This must be fixed before merging. Set `JCODE_HOME` to a temporary directory before the first load or save, keep that isolation active through cleanup, and restore the previous environment afterward.

### Issue 2
crates/jcode-tui/src/tui/app/commands.rs:3521-3525
`/settings` mixes saved and active values when `JCODE_RISK_GATE_ENABLED` is set:
- `Config::load()` applies the override, so `Saved default` shows the environment value rather than the file's value.
- With `JCODE_RISK_GATE_ENABLED=0`, `/settings risk-gate on` reports enabled while the gate remains off.

This is a non-blocking reporting issue: users cannot reliably tell whether protection is active or what will apply after removing the override. Read the saved value without overrides, and make the save message show when an override still controls the gate.

### Issue 3
crates/jcode-base/src/config/env_overrides.rs:930-934
With saved `risk_gate_enabled = false` and `JCODE_RISK_GATE_ENABLED=garbage`, this override leaves the config value false, so `/config` reports disabled. The bash gate treats the same environment value as enabled and still requires justification for risky commands. Execution confirmed that the summary says disabled while bash refuses the command.

This is a non-blocking status-consistency issue: users cannot rely on the displayed configuration to predict command behavior. Use `env_allows_gate` here too so the config summary agrees with the active gate.

```suggestion
        if let Ok(v) = std::env::var("JCODE_RISK_GATE_ENABLED") {
            self.provider.risk_gate_enabled = risk_gate::env_allows_gate(&v);
        }
```

### Issue 4
crates/jcode-base/src/config/default_file.rs:576-581
The generated config puts `risk_gate_enabled` under `[server]`, but the gate reads `provider.risk_gate_enabled`. Uncommenting this example and setting it to `false` parses successfully but leaves the gate enabled. Users following the example therefore cannot turn the gate off through the config file. This is non-blocking; move the example into the existing `[provider]` section.

### Issue 5
docs/ssh-slash-commands.md:undefined-72
This row promises that SSH users can inspect and change the client risk-gate preference with `/settings`. Both `/settings` and `/settings risk-gate off` instead display “This command's local fallback is unavailable in SSH mode.” The toggle leaves the saved preference unchanged and sends nothing to the remote session.

This is a non-blocking user-flow issue: users following the new instructions cannot inspect or change the promised setting. Mark `/settings` as blocked and remove the claim about local pre-send confirmation, unless SSH support is added.

```suggestion
| `/settings` | Blocked | No supported SSH implementation. The command does not show or change the VM's risk-gate policy. |
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds a saved bash risk-gate preference and /settings commands, with protection enabled by default.

• The bash risk gate can be switched on or off from /settings.
• Terminal color reports can arrive in slower fragments without being mistaken for user input.
• The browser tool’s intent field now explains the reason for a call.
• Sparkline bars handle a zero maximum without dividing by zero.
• Platform checks, tests, and code cleanups change without another user-facing behavior change.

_{Reviews (20) · Last reviewed commit: "chore(budgets): refresh ratchet baseline..." · Reviewed by Greptile}

[greptile-apps]

Tests overwrite real settings

If JCODE_HOME is unset, running a settings test by itself rewrites the developer's real ~/.jcode/config.toml: with_clean_config loads and saves before create_test_app installs the temporary test home. Executing the existing settings-display test against isolated home directories confirmed that it changes a saved risk_gate_enabled = false to true and replaces malformed configuration with defaults, even though the test passes.

This must be fixed before merging. Set JCODE_HOME to a temporary directory before the first load or save, keep that isolation active through cleanup, and restore the previous environment afterward.

Artifacts

Evidence from the check

• The executed Python script prepares two disposable home configurations and invokes the exact existing settings-display test, demonstrating the candidate without modifying production code.

Command output from the check

• The reproducer captured both original files, their hashes, and their parsed state before execution, establishing a disabled gate and recoverable malformed configuration.

Command output from the check

• The captured commands, environments, exit codes, and test output show that both exact test invocations passed while changing their caller-home configuration files.

Command output from the check

• The reproducer captured both complete files after execution, showing identical default-expanded TOML with the risk gate enabled and the original comments lost.

_{Ran code and verified through TREX}

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-tui/src/tui/app/commands_tests.rs
Line: 457-464

Comment:
**Tests overwrite real settings**

If `JCODE_HOME` is unset, running a settings test by itself rewrites the developer's real `~/.jcode/config.toml`: `with_clean_config` loads and saves before `create_test_app` installs the temporary test home. Executing the existing settings-display test against isolated home directories confirmed that it changes a saved `risk_gate_enabled = false` to `true` and replaces malformed configuration with defaults, even though the test passes.

This must be fixed before merging. Set `JCODE_HOME` to a temporary directory before the first load or save, keep that isolation active through cleanup, and restore the previous environment afterward.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Settings show the wrong state

/settings mixes saved and active values when JCODE_RISK_GATE_ENABLED is set:

• Config::load() applies the override, so Saved default shows the environment value rather than the file's value.
• With JCODE_RISK_GATE_ENABLED=0, /settings risk-gate on reports enabled while the gate remains off.

This is a non-blocking reporting issue: users cannot reliably tell whether protection is active or what will apply after removing the override. Read the saved value without overrides, and make the save message show when an override still controls the gate.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-tui/src/tui/app/commands.rs
Line: 3619-3623

Comment:
**Settings show the wrong state**

`/settings` mixes saved and active values when `JCODE_RISK_GATE_ENABLED` is set:
- `Config::load()` applies the override, so `Saved default` shows the environment value rather than the file's value.
- With `JCODE_RISK_GATE_ENABLED=0`, `/settings risk-gate on` reports enabled while the gate remains off.

This is a non-blocking reporting issue: users cannot reliably tell whether protection is active or what will apply after removing the override. Read the saved value without overrides, and make the save message show when an override still controls the gate.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Config and bash disagree

With saved risk_gate_enabled = false and JCODE_RISK_GATE_ENABLED=garbage, this override leaves the config value false, so /config reports disabled. The bash gate treats the same environment value as enabled and still requires justification for risky commands. Execution confirmed that the summary says disabled while bash refuses the command.

This is a non-blocking status-consistency issue: users cannot rely on the displayed configuration to predict command behavior. Use env_allows_gate here too so the config summary agrees with the active gate.

Suggested change

	if let Ok(v) = std::env::var("JCODE_RISK_GATE_ENABLED") {
	if let Some(enabled) = risk_gate::env_override(&v) {
	self.provider.risk_gate_enabled = enabled;
	}
	}
	if let Ok(v) = std::env::var("JCODE_RISK_GATE_ENABLED") {
	self.provider.risk_gate_enabled = risk_gate::env_allows_gate(&v);
	}

Artifacts

Evidence from the check

• The authored harness loads isolated saved configuration, prints the real summary, invokes registered bash against disposable files, and asserts the observed control and candidate outcomes.

Evidence from the check

• The authored runner compiles the Rust harness against cached head libraries and captures both executions with command, working directory, environment, and exit code.

Command output from the check

• The first compilation captured a cached serde_json type mismatch before behavioral execution, showing the resolved harness setup issue.

Command output from the check

• Compiling with the matching cached dependency artifact exited zero, establishing that the uploaded harness was executable.

Command output from the check

• The real configuration summary reported disabled and bash deleted only the disposable fixture, showing agreement in the unset-variable control.

Command output from the check

• The real summary still reported disabled while bash requested justification and preserved the canary, confirming the supplied disagreement.

Command output from the check

• Executed revision, status, checksum, and library-listing commands recorded the requested head and authored sources with no tracked production edits.

_{Ran code and verified through TREX}

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-base/src/config/env_overrides.rs
Line: 909-913

Comment:
**Config and bash disagree**

With saved `risk_gate_enabled = false` and `JCODE_RISK_GATE_ENABLED=garbage`, this override leaves the config value false, so `/config` reports disabled. The bash gate treats the same environment value as enabled and still requires justification for risky commands. Execution confirmed that the summary says disabled while bash refuses the command.

This is a non-blocking status-consistency issue: users cannot rely on the displayed configuration to predict command behavior. Use `env_allows_gate` here too so the config summary agrees with the active gate.

```suggestion
        if let Ok(v) = std::env::var("JCODE_RISK_GATE_ENABLED") {
            self.provider.risk_gate_enabled = risk_gate::env_allows_gate(&v);
        }
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Config example uses wrong section

The generated config puts risk_gate_enabled under [server], but the gate reads provider.risk_gate_enabled. Uncommenting this example and setting it to false parses successfully but leaves the gate enabled. Users following the example therefore cannot turn the gate off through the config file. This is non-blocking; move the example into the existing [provider] section.

Artifacts

Authored isolated configuration and policy test

• The executed Rust test generates the real default configuration, loads each variant, and calls only the refusal function, demonstrating the behavior without executing destructive commands.

Authored validation runner and exact commands

• The executed Python runner temporarily installs the test, builds it, captures three isolated runs, and restores the original source, making the validation reproducible.

Validation test compilation

• The captured Cargo command compiled the temporary test against the selected workspace packages and exited successfully.

Before uncommenting the generated example

• The real generated default configuration loaded with the gate enabled and returned a policy refusal, establishing the baseline.

After uncommenting the example as false

• The generated configuration with server.risk_gate_enabled=false parsed successfully but left the provider setting true and still returned a refusal, confirming the supplied finding.

Control with false under the provider table

• The same generated configuration with provider.risk_gate_enabled=false loaded the setting as false and returned no refusal, isolating table placement as the cause.

Temporary source instrumentation cleanup

• The captured git diff check exited zero after the runner restored the instrumented source, confirming no production changes remained.

Verified head and relevant source citations

• Executed git and numbered-source commands captured the requested head, clean tracked diff, misplaced example, and actual configuration read, preserving the relevant citations.

_{Ran code and verified through TREX}

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-base/src/config/default_file.rs
Line: 536-541

Comment:
**Config example uses wrong section**

The generated config puts `risk_gate_enabled` under `[server]`, but the gate reads `provider.risk_gate_enabled`. Uncommenting this example and setting it to `false` parses successfully but leaves the gate enabled. Users following the example therefore cannot turn the gate off through the config file. This is non-blocking; move the example into the existing `[provider]` section.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[alecuba16]

Rebased onto the fixed master line (tip 0ba439f68, CI green) and force-pushed as 4e0bcd383. Guardrail budgets regenerated on the new base. Clippy -D warnings and fmt clean.

[greptile-apps]

SSH toggle instructions fail

This row promises that SSH users can inspect and change the client risk-gate preference with /settings. Both /settings and /settings risk-gate off instead display “This command's local fallback is unavailable in SSH mode.” The toggle leaves the saved preference unchanged and sends nothing to the remote session.

This is a non-blocking user-flow issue: users following the new instructions cannot inspect or change the promised setting. Mark /settings as blocked and remove the claim about local pre-send confirmation, unless SSH support is added.

Suggested change

	| `/settings` | UI | Show client risk-gate state, saved default and `JCODE_RISK_GATE_ENABLED` override. `/settings risk-gate on|off` writes the saved default in laptop config; the gate only controls this terminal's local pre-send confirmation, never VM session policy. |
	| `/settings` | Blocked | No supported SSH implementation. The command does not show or change the VM's risk-gate policy. |

Artifacts

Base revision SSH command execution

• Executed both commands through connected and disconnected dispatch on the scope base and captured messages, terminal frames, config bytes, and wire output; the test completed successfully.

PR head rejects both SSH settings commands

• Executed both commands through connected and disconnected dispatch on PR head and asserted visible rejection, unchanged config, and no wire traffic; all four cases reproduced the blocked flow.

Base revision terminal rendering and observed state

• Saved actual ratatui terminal buffers alongside command messages, configuration contents, and wire output from the base run; these are captured runtime data.

PR head terminal rendering and unchanged client preference

• Saved actual ratatui terminal buffers and observed state for both SSH settings commands on PR head; the rejection is visible and the saved preference remains enabled.

Full executed Rust reproduction test

• Contains the complete temporary Rust test that invokes production dispatch, renders the terminal UI, checks configuration bytes, and observes socket-pair traffic; the decisive evidence is reproducible.

Full executed base and head validation driver

• Contains the complete executed driver for isolated offline Cargo runs, revision switching, output capture, and tracked-source restoration; both recorded runs exited successfully.

_{Ran code and verified through TREX}

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/ssh-slash-commands.md
Line: 50

Comment:
**SSH toggle instructions fail**

This row promises that SSH users can inspect and change the client risk-gate preference with `/settings`. Both `/settings` and `/settings risk-gate off` instead display “This command's local fallback is unavailable in SSH mode.” The toggle leaves the saved preference unchanged and sends nothing to the remote session.

This is a non-blocking user-flow issue: users following the new instructions cannot inspect or change the promised setting. Mark `/settings` as blocked and remove the claim about local pre-send confirmation, unless SSH support is added.

```suggestion
| `/settings` | Blocked | No supported SSH implementation. The command does not show or change the VM's risk-gate policy. |
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[alecuba16]

Rebased onto a green master baseline and refreshed the four ratchet budgets (code size, test size, panic, swallowed error) to match the files this branch actually grows, as two chore commits on the tip. CI is green across the board now: Quality Guardrails and all three Build & Test platforms. Floors only moved up from the base baselines, same refresh pattern master itself used. Ready for review.