feat(tui): confirmed opt-out for model-bound key redaction ([redaction] model_bound)

[SparkofSpike]

Why

CodeWhale already has a mandatory algorithm that redacts credential‑like information. However, this redaction causes unnecessary trouble during development. For example, I'm currently building a browser extension: the server backend generates an API key, which I need to paste into the extension's settings page to use it. But CodeWhale keeps redacting the key, wasting many tokens and even overwriting the API key with [redacted] when modifying files, which causes the key to be lost.

We should add a configurable option to disable redaction. I admit that while this design is inconvenient, it is there for privacy and security. In this PR’s changes, we’ve paid special attention to that: the warning will be shown twice, clearly stating the possible serious consequences.

Summary

Codewhale masks credential-shaped values in tool output before it is sent to an upstream model (configured secrets plus the CredentialShaped structural pass, see crates/config/src/persistence.rs). That boundary makes it impossible for the model to read and then quote files that contain real credentials: a read_file result is redacted, and a whole-file rewrite can overwrite the true token with [redacted].

This change adds a deliberate, documented opt-out that treats lowering that boundary as a security decision rather than a plain boolean:

• New config table [redaction] model_bound = "enabled" (default) / "disabled". The value parses forgivingly: true/false, "on"/off", and any casing of "enabled"/"disabled" all work (false/"off" mean "disabled").
• "disabled" only records a request. After a restart the interactive TUI shows a two-stage startup gate: the first screen explains the opt-out and shows a bold red warning; pressing 1/Y advances to a final-confirmation screen ("are you really sure?") that repeats the red warning, and only a second 1/Y persists a receipt to ~/.codewhale/redaction-state.json and takes effect.
• The receipt is bound to the config.toml it was made against: setting the field back to "enabled", or rewriting config.toml after the confirmation (including an enabled→disabled round trip with zero processes in between), invalidates it, so a later "disabled" request always asks for a fresh confirmation.
• Fail-closed everywhere: any unconfirmed request resolves to Enabled in every process, including headless/exec runs, hooks, and automations, which never confirm anything.
• The opt-out only relaxes masking on structured ToolResult blocks of the main conversation. Routing/classification summaries and durable goal-state text keep always-on redaction.

Changes

• crates/config/src/redaction.rs (new): [redaction] types, forgiving ModelBoundMasking deserialization, the receipt state file, confirmation_required / effective_masking decisions, and the config-mtime-bound receipt invalidation with best-effort sweep.
• crates/config/src/lib.rs: ConfigToml.redaction field plus redaction_model_bound_masking() accessor.
• crates/tui/src/config.rs: TUI Config accepts [redaction] and exposes model_bound_redaction(); merge_config carries the table.
• crates/tui/src/client.rs: DeepSeekClient.model_bound_masking — set only when the opt-out is confirmed — gates the ToolResult redaction in prepare_model_bound_request; other redaction paths are untouched.
• crates/tui/src/tui/redaction_gate.rs (new): two-stage gate rendering with the red bold warning (palette STATUS_ERROR + BOLD) and explicit-key actions.
• crates/tui/src/tui/app.rs / app/init.rs: redaction_gate / redaction_gate_confirming state on App.
• crates/tui/src/tui/ui/event_loop.rs: arms the gate at startup before the engine spawns; two-stage key handling (1/Y confirm, 2/U back-or-keep, 3/N and Esc quit, Enter never confirms); on final confirm the engine is rebuilt (Shutdown + spawn_tui_engine) so the client picks up the effective mode, same pattern as the provider-rollback respawn.
• crates/tui/src/tui/ui/frame.rs: gate renders full-screen above the launch surface while active.
• Localization: 13 new RedactionGate* MessageIds added to the enum and ALL_MESSAGE_IDS, translated in all 15 complete locale packs (the zh packs use the polite 您 and include the requested red warning).
• Docs: docs/CONFIGURATION.md section and config.example.toml comments document the table, the two-stage confirmation, the receipt-binding rule, and the forgiving value spellings.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Tests

Testing

• cargo fmt --all -- --check — clean
• cargo clippy -p codewhale-config --all-targets — no warnings
• cargo test -p codewhale-config — 640 passed, 0 failed (includes the redaction decision/lifecycle tests: default-path lifecycle, forgiving boolean/on-off spellings, corrupt receipt, enabled-invalidates-receipt, config-rewrite-invalidates-receipt)
• cargo test -p codewhale-tui --lib opt_out — 9 passed (includes the two new regression tests: confirmed opt-out keeps tool output byte-exact; unconfirmed request stays masked)
• cargo test -p codewhale-tui --lib redaction_gate — 3 passed (two-stage rails and red warning, narrow-terminal rendering for both stages)
• cargo test -p codewhale-tui --lib localization::tests — 50 passed (15-locale key parity)
• cargo build --release -p codewhale-tui — succeeds; the executable was exercised (--version, config parsing with model_bound = "disabled")
• Manual TUI verification of the two-stage gate flow by the author

Note: cargo clippy --workspace and cargo test --workspace were not run in full (Windows, long release builds); the focused crate suites above are green and the PR CI gate will run the workspace gates. On Windows the tui unit-test binary can hit a stack overflow under the default 2 MB thread stack with the v0.9.12 codebase; the affected suites were verified with RUST_MIN_STACK=16MB, and the config lifecycle test includes a 300 ms backoff for the transient exclusive file lock Windows real-time AV holds on freshly written files (commented in the test).

Checklist

• Updated docs or comments as needed
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes
• Harvested/co-authored credit uses a GitHub numeric noreply address

Related Issues

No-Issue: feature request from the author (editing files that contain real credentials); no issue number exists yet.

[Hmbown]

Why

CodeWhale already has a mandatory algorithm that redacts credential‑like information. However, this redaction causes unnecessary trouble during development. For example, I'm currently building a browser extension: the server backend generates an API key, which I need to paste into the extension's settings page to use it. But CodeWhale keeps redacting the key, wasting many tokens and even overwriting the API key with [redacted] when modifying files, which causes the key to be lost.

We should add a configurable option to disable redaction. I admit that while this design is inconvenient, it is there for privacy and security. In this PR’s changes, we’ve paid special attention to that: the warning will be shown twice, clearly stating the possible serious consequences.

Summary

Codewhale masks credential-shaped values in tool output before it is sent to an upstream model (configured secrets plus the CredentialShaped structural pass, see crates/config/src/persistence.rs). That boundary makes it impossible for the model to read and then quote files that contain real credentials: a read_file result is redacted, and a whole-file rewrite can overwrite the true token with [redacted].

This change adds a deliberate, documented opt-out that treats lowering that boundary as a security decision rather than a plain boolean:

• New config table [redaction] model_bound = "enabled" (default) / "disabled". The value parses forgivingly: true/false, "on"/off", and any casing of "enabled"/"disabled" all work (false/"off" mean "disabled").

• "disabled" only records a request. After a restart the interactive TUI shows a two-stage startup gate: the first screen explains the opt-out and shows a bold red warning; pressing 1/Y advances to a final-confirmation screen ("are you really sure?") that repeats the red warning, and only a second 1/Y persists a receipt to ~/.codewhale/redaction-state.json and takes effect.

• The receipt is bound to the config.toml it was made against: setting the field back to "enabled", or rewriting config.toml after the confirmation (including an enabled→disabled round trip with zero processes in between), invalidates it, so a later "disabled" request always asks for a fresh confirmation.

• Fail-closed everywhere: any unconfirmed request resolves to Enabled in every process, including headless/exec runs, hooks, and automations, which never confirm anything.

• The opt-out only relaxes masking on structured ToolResult blocks of the main conversation. Routing/classification summaries and durable goal-state text keep always-on redaction.

Changes

• crates/config/src/redaction.rs (new): [redaction] types, forgiving ModelBoundMasking deserialization, the receipt state file, confirmation_required / effective_masking decisions, and the config-mtime-bound receipt invalidation with best-effort sweep.

• crates/config/src/lib.rs: ConfigToml.redaction field plus redaction_model_bound_masking() accessor.

• crates/tui/src/config.rs: TUI Config accepts [redaction] and exposes model_bound_redaction(); merge_config carries the table.

• crates/tui/src/client.rs: DeepSeekClient.model_bound_masking — set only when the opt-out is confirmed — gates the ToolResult redaction in prepare_model_bound_request; other redaction paths are untouched.

• crates/tui/src/tui/redaction_gate.rs (new): two-stage gate rendering with the red bold warning (palette STATUS_ERROR + BOLD) and explicit-key actions.

• crates/tui/src/tui/app.rs / app/init.rs: redaction_gate / redaction_gate_confirming state on App.

• crates/tui/src/tui/ui/event_loop.rs: arms the gate at startup before the engine spawns; two-stage key handling (1/Y confirm, 2/U back-or-keep, 3/N and Esc quit, Enter never confirms); on final confirm the engine is rebuilt (Shutdown + spawn_tui_engine) so the client picks up the effective mode, same pattern as the provider-rollback respawn.

• crates/tui/src/tui/ui/frame.rs: gate renders full-screen above the launch surface while active.

• Localization: 13 new RedactionGate* MessageIds added to the enum and ALL_MESSAGE_IDS, translated in all 15 complete locale packs (the zh packs use the polite 您 and include the requested red warning).

• Docs: docs/CONFIGURATION.md section and config.example.toml comments document the table, the two-stage confirmation, the receipt-binding rule, and the forgiving value spellings.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

• New feature (non-breaking change which adds functionality)

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

• Documentation update

• Refactoring (no functional changes)

• Tests

Testing

• cargo fmt --all -- --check — clean

• cargo clippy -p codewhale-config --all-targets — no warnings

• cargo test -p codewhale-config — 640 passed, 0 failed (includes the redaction decision/lifecycle tests: default-path lifecycle, forgiving boolean/on-off spellings, corrupt receipt, enabled-invalidates-receipt, config-rewrite-invalidates-receipt)

• cargo test -p codewhale-tui --lib opt_out — 9 passed (includes the two new regression tests: confirmed opt-out keeps tool output byte-exact; unconfirmed request stays masked)

• cargo test -p codewhale-tui --lib redaction_gate — 3 passed (two-stage rails and red warning, narrow-terminal rendering for both stages)

• cargo test -p codewhale-tui --lib localization::tests — 50 passed (15-locale key parity)

• cargo build --release -p codewhale-tui — succeeds; the executable was exercised (--version, config parsing with model_bound = "disabled")

• Manual TUI verification of the two-stage gate flow by the author

Note: cargo clippy --workspace and cargo test --workspace were not run in full (Windows, long release builds); the focused crate suites above are green and the PR CI gate will run the workspace gates. On Windows the tui unit-test binary can hit a stack overflow under the default 2 MB thread stack with the v0.9.12 codebase; the affected suites were verified with RUST_MIN_STACK=16MB, and the config lifecycle test includes a 300 ms backoff for the transient exclusive file lock Windows real-time AV holds on freshly written files (commented in the test).

Checklist

• Updated docs or comments as needed

• Added or updated tests where relevant

• Verified TUI behavior manually if UI changes

• Harvested/co-authored credit uses a GitHub numeric noreply address

Related Issues

No-Issue: feature request from the author (editing files that contain real credentials); no issue number exists yet.

Thank you so much for this!!

[Hmbown]

Hi @SparkofSpike — thank you for this, seriously. This is a well-shaped contribution to a genuinely hard boundary: the double-confirmation gate, the receipt bound to the exact config.toml bytes, the headless/exec fail-closed default, and the config-rewrite invalidation are exactly the properties we would have demanded in review. The doc comments and config.example.toml prose are excellent.

Status and next steps:

• Scope call (founder decision, not a code issue): 0.9.13 is currently a regression/defect-fix release on a tight clock (paste regression Multiline paste split into separate messages per line (v9.12 regression from Y-7 fix) #5981, truncated tool args Engine: a tool call truncated at the provider's output limit is repaired into valid JSON and executed #5986, ACP schema serve --acp initialize response violates the ACP schema: sessionCapabilities.list is a boolean instead of an object — strict clients (JetBrains IDEA) fail to connect #5969…). A new opt-out on the credential-masking boundary is the kind of change that wants its own release cycle with full scrutiny. Our intent is to land this for the next release unless @Hmbown says otherwise — flagging here so the timing expectation is explicit, not silent.
• The base moved under you today (several merges); it will need an update-branch/rebase pass before CI is meaningful again. We can drive that from our side.
• Review pass we will run before merge: (1) every read site of effective_masking fails closed on absent/malformed receipts; (2) the receipt binding cannot be replayed across config edits; (3) codewhale exec/hooks/app-server entry points cannot reach a disabled state through any path other than the interactive gate; (4) tests pin each of those.

Thanks again — real users hitting real friction (dev-loop key pasting) with a security-careful fix is exactly the contribution that makes this project better.

[SparkofSpike]

Thanks for the review pass and the scope call — next-release timing is fine on our side.

The branch is now rebased onto current main (b0c5241); the only conflict was the validate_base_url_security signature change, resolved by keeping both the new argument and the confirmation-gated masking decision. CI is green on the new base (all checks except the slow macos tail).

On the four review points, current state maps as follows:

1. Fail-closed reads — read_state returns the safe default for absent/unreadable/malformed receipts (absent_state_is_not_confirmed, corrupt_state_reads_as_unconfirmed pin it); effective_masking is the single decision point every caller resolves through.
2. No replay across config edits — the receipt is bound by config.toml mtime, so any rewrite after the confirmation (including an enabled→disabled round trip with zero processes in between) invalidates it and forces a fresh confirmation; default_path_lifecycle_requires_confirmation_before_disabling covers exactly that round trip.
3. Non-interactive entries — record_model_bound_disabled_confirmation is reachable only from the interactive startup gate; exec/hooks/app-server resolve effective_masking to Enabled whenever no fresh receipt exists.
4. Tests — each case above is pinned in crates/config/src/redaction.rs plus the gate and client opt-out tests.

Happy to adjust anything the review pass turns up.

[SparkofSpike]

Well, the Test CI has timed out. Awaiting manual merge.