TUI: make deny-by-default approval selection configurable and clearly explained

[JayBeest]

Description:

Starting from v0.9.4, I noticed that the default highlighted option in the TUI permission request dialog has changed. This alters the established interaction pattern and may cause users to accidentally deny an action when they intend to quickly confirm it.

Steps to Reproduce:

In the CodeWhale TUI (v0.9.4), trigger an action that requires user approval for tool usage (e.g., executing a shell command).

Observe the permission request dialog.

Actual Behavior:

The dialog defaults to (or highlights) the option: [3 / d / n] Deny this call.

This means that if a user habitually presses Enter to confirm, they will deny the tool execution.

Expected Behavior:

Based on previous releases, the default highlighted option should be: [1 / y] Allow once.

This way, pressing Enter quickly approves the action, which aligns with intuition and previous usage habits.

Screenshot:

Environment:

CodeWhale: v0.9.4

OS: macOS Tahoe 26.5.2

Terminal: iTerm2 3.6.11

Additional Context:

I'm not sure whether this change is intentional or an unintended regression. If it was deliberately made to improve security (e.g., defaulting to deny for high-risk operations), then this issue could be converted into a feature discussion or a documentation update request. Otherwise, it may be a bug that should be fixed to restore a smoother interaction flow.

[github-actions]

Thanks @JayBeest for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[JayBeest]

After checking the CHANGELOG, I found this is intentional, listed under Changed as:

deny-by-default approval cards (PR #5090)

I understand this is likely a security improvement (default-deny), and I appreciate the rationale. However, this does break the muscle memory for users who are used to pressing Enter to quickly approve safe/trusted actions.

Proposal / Question:

Would the maintainers consider adding a user-configurable setting to control the default highlighted option? For example:

[approval]
default_action = "allow_once"  # or "deny"

This way, users who prefer the old behaviour can restore it, while the secure default remains for new users.

If this is not something the team wants to support, I'd suggest at least documenting this behavioral change prominently in the release notes or user guide, so others don't get confused.

Would the team be open to either of these paths? Happy to hear your thoughts.

[JayBeest]

I initially thought this was a bug when I first saw it.
Now I'm not so sure (I know it is not), and I can work around it.
Just noting it here in case others hit the same friction.

[Hmbown]

Thank you @JayBeest for tracing this to the intentional deny-by-default change in #5088 / #5090. I am keeping your report as the canonical v0.9.7 follow-up: preserve Deny as the safe default, then evaluate an explicit user setting and make the behavior unmistakable in-product and in release notes. Retitling it to reflect that accepted scope rather than leaving it framed as an unexplained regression.