## Description
This PR fixes Issue #421 where commands with pipes (e.g., `grep -R ...
-n | head -n 20`) were failing to execute properly after PR #391 was
merged.
## Changes
- Modified the `requiresShell` function to only enable shell mode when
the command is a single string containing shell operators
- Added logic to handle the case where shell operators are passed as
separate arguments
- Added comprehensive tests to verify the fix
## Root Cause
The issue was that the `requiresShell` function was detecting shell
operators like `|` even when they were passed as separate arguments,
which caused the command to be executed with `shell: true`
unnecessarily. This was causing syntax errors when running commands with
pipes.
## Testing
- Added unit tests to verify the fix
- Manually tested with real commands using pipes
- Ensured all existing tests pass
Fixes#421
## Description
This PR implements multi-line input support for Codex when it asks for
user feedback (Issue #344). Users can now use Shift+Enter to add new
lines in their responses, making it easier to provide formatted code
snippets, lists, or other structured content.
## Changes
- Replace the single-line TextInput component with the
MultilineTextEditor component in terminal-chat-input.tsx
- Add support for Shift+Enter to create new lines
- Update key handling logic to properly handle history navigation in a
multi-line context
- Add reference to the editor to access cursor position information
- Update help text to inform users about the Shift+Enter functionality
- Add tests for the new functionality
## Testing
- Added new test file (terminal-chat-input-multiline.test.tsx) to test
the multi-line input functionality
- All existing tests continue to pass
- Manually tested the feature to ensure it works as expected
## Fixes
Closes#344
## Screenshots
N/A
## Additional Notes
This implementation maintains backward compatibility while adding the
requested multi-line input functionality. The UI remains clean and
intuitive, with a simple hint about using Shift+Enter for new lines.
---------
Co-authored-by: Thibault Sottiaux <tibo@openai.com>
# Shell Command Explanation Option
## Description
This PR adds an option to explain shell commands when the user is
prompted to approve them (Fixes#110). When reviewing a shell command,
users can now select "Explain this command" to get a detailed
explanation of what the command does before deciding whether to approve
or reject it.
## Changes
- Added a new "EXPLAIN" option to the `ReviewDecision` enum
- Updated the command review UI to include an "Explain this command (x)"
option
- Implemented the logic to send the command to the LLM for explanation
using the same model as the agent
- Added a display for the explanation in the command review UI
- Updated all relevant components to pass the explanation through the
component tree
## Benefits
- Improves user understanding of shell commands before approving them
- Reduces the risk of approving potentially harmful commands
- Enhances the educational aspect of the tool, helping users learn about
shell commands
- Maintains the same workflow with minimal UI changes
## Testing
- Manually tested the explanation feature with various shell commands
- Verified that the explanation is displayed correctly in the UI
- Confirmed that the user can still approve or reject the command after
viewing the explanation
## Screenshots
## Additional Notes
The explanation is generated using the same model as the agent, ensuring
consistency in the quality and style of explanations.
---------
Signed-off-by: crazywolf132 <crazywolf132@gmail.com>
## Problem
There's a security vulnerability in the current implementation where
shell commands are being executed without requesting user permission
even when in 'suggest' mode. According to our documentation:
> In **Suggest** mode (default): All file writes/patches and **ALL
shell/Bash commands** should require approval.
However, the current implementation in `approvals.ts` was auto-approving
commands deemed "safe" by the `isSafeCommand` function, bypassing the
user permission requirement. This is a security risk as users expect all
shell commands to require explicit approval in 'suggest' mode.
## Solution
This PR fixes the issue by modifying the `canAutoApprove` function in
`approvals.ts` to respect the 'suggest' mode policy for all shell
commands:
1. Added an early check at the beginning of `canAutoApprove` to
immediately return `{ type: "ask-user" }` when the policy is `suggest`,
regardless of whether the command is considered "safe" or not.
2. Added a similar check in the bash command handling section to ensure
bash commands also respect the 'suggest' mode.
3. Updated tests to verify the new behavior, ensuring that all shell
commands require approval in 'suggest' mode, while still being
auto-approved in 'auto-edit' and 'full-auto' modes when appropriate.
## Testing
All tests pass, confirming that the fix works as expected. The updated
tests verify that:
- All commands (even "safe" ones) require approval in 'suggest' mode
- Safe commands are still auto-approved in 'auto-edit' mode
- Bash commands with redirects still require approval in all modes
This change ensures that the behavior matches what's documented and what
users expect, improving security by requiring explicit permission for
all shell commands in the default 'suggest' mode.
## Description
This PR fixes the issue where the CLI can't continue after interrupting
the assistant with ESC ESC (Fixes#114). The problem was caused by
duplicate code in the `cancel()` method and improper state reset after
cancellation.
## Changes
- Fixed duplicate code in the `cancel()` method of the `AgentLoop` class
- Added proper reset of the `currentStream` property in the `cancel()`
method
- Created a new `AbortController` after aborting the current one to
ensure future tool calls work
- Added a system message to indicate the interruption to the user
- Added a comprehensive test to verify the fix
## Benefits
- Users can now continue using the CLI after interrupting the assistant
- Improved user experience by providing feedback when interruption
occurs
- Better state management in the agent loop
## Testing
- Added a dedicated test that verifies the agent can process new input
after cancellation
- Manually tested the fix by interrupting the assistant and confirming
that new input is processed correctly
---------
Signed-off-by: crazywolf132 <crazywolf132@gmail.com>
Brayden MoonandGitHub
