Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 442dbf6884
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| delete state.pendingConfirmations[confirmationKey]; | ||
| saveState(state); |
There was a problem hiding this comment.
Do not clear pending confirmation before guard re-check
consumePendingConfirmationAction deletes the user's pending confirmation immediately, but handleCommand still calls requireHighValueConfirmation for the returned action (send/swap/bridge). Because the pending record is already gone, the guard creates a new confirmation instead of allowing execution, so affirmative replies like evet/yes never complete the transaction and keep re-prompting for confirmation.
Useful? React with 👍 / 👎.
| const amountMatch = normalized.match(/(\d+(?:[.,]\d{1,6})?)/); | ||
| const amount = amountMatch?.[1]?.replace(",", "."); |
There was a problem hiding this comment.
Avoid extracting send amount from address digits
The deterministic send parser takes the first numeric token from the entire message, which can come from the recipient address when users put the address before the amount. In inputs like “send to 0x... 1 ETH”, amount becomes 0 (or other address digits), the parser returns a malformed send action, and the LLM fallback is skipped, leading to false invalid-amount errors for otherwise valid commands.
Useful? React with 👍 / 👎.
Summary
evet/yesfor pending confirmations instead of falling back to chat mode