[BUG] Auto approve command suggestions are editable fields even though they have no edit functionality

[DarkEden-coding]

Problem (one or two sentences)

The fields that are suggestions for auto-accept commands are able to be clicked and edited, however when pressing Enter or clicking out of the field, the field resets. These fields should be made non-editable or their edits should actually have a functionality.

Context (who is affected and when)

Everyone, small ux issue

Reproduction steps

Have the agent run any command that is not auto-accepted and click on the auto-accept suggestions.

Expected result

Either you can not click on these suggestions, or making the edits actually changes the auto-accept command that will be added to the list.

Actual result

Your edits are reverted immediately.

Variations tried (optional)

No response

App Version

3.47.3

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root cause: In webview-ui/src/components/chat/CommandPatternSelector.tsx, the setEditState() helper (line 58) uses value ?? pattern as the stored value. When the user finishes editing by pressing Enter (line 105) or clicking away / blur (line 102), the call setEditState(item.pattern, false) omits the value argument, so it falls back to the original pattern key -- discarding whatever the user typed.

Proposed fix (option chosen: make edits persist, since the allow/deny buttons already use editState.value):

1. On blur (line 102): change setEditState(item.pattern, false) to setEditState(item.pattern, false, editState.value) so the edited text is preserved when the input loses focus.
2. On Enter (line 105): same change -- setEditState(item.pattern, false, editState.value) to keep the edited value.
3. On Escape (line 108): leave as-is (setEditState(item.pattern, false, item.pattern)) since Escape should revert.
4. Update the existing tests in CommandPatternSelector.spec.tsx and add a new test verifying that edited values persist after blur/Enter and revert on Escape.

This approach is minimal and preserves the existing UX intent: users can customize a pattern before adding it to the allowed/denied list via the checkmark/X buttons.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[DarkEden-coding]

@roomote check to make sure that the changed command prefix will actually be consumed upon acceptance

[roomote]

Good call -- I'll trace the full acceptance path to make sure the edited prefix is actually consumed when the user clicks allow/deny. Implementing now and will open a PR shortly.

[roomote]

Opened PR #11412 with my attempt at addressing this. The fix ensures the edited command prefix is preserved on blur/Enter (via a one-line change in the setEditState functional updater) and is what gets passed to onAllowPatternChange/onDenyPatternChange when the user clicks accept/deny. Five new tests verify the end-to-end flow. Feedback welcome!