fix(menu): restore paste in macOS native dialogs

[pstanton237]

Summary

• preserve Orca coordinated paste when a BrowserWindow is focused
• forward Edit > Paste to the native macOS first responder when no BrowserWindow is focused
• keep Windows and Linux behavior unchanged

The custom Edit > Paste handler replaced the Electron paste role so terminal and native-chat surfaces could coordinate clipboard ownership. When a native macOS open/save panel owned focus, BrowserWindow.getFocusedWindow() returned null and the handler became a no-op.

Screenshots

Before the fix, Cmd+V does not insert the clipboard path into the macOS Go to Folder field, while context-menu Paste remains available:

Testing

• pnpm lint
• pnpm typecheck
• focused menu tests: 17 passed with one platform-specific skip
• pnpm build under Node 24
• added regression tests covering exact-once renderer routing, the macOS native responder fallback, and unchanged Linux/Windows behavior

The new macOS regression test fails against upstream main and passes on this branch.

AI Review Report

The AI coding-agent review and CodeRabbit checked exact-once routing, Electron focus behavior, and platform boundaries. No actionable code issues were found.

• macOS: a focused Orca BrowserWindow still receives exactly one ui:appMenuPaste; only the no-focused-window path calls Menu.sendActionToFirstResponder("paste:")
• Linux and Windows: the native responder fallback is not invoked, and the existing CmdOrCtrl+V accelerator remains unchanged
• shortcuts, labels, file paths, shell behavior, SSH sessions, and folder workspaces are otherwise untouched

Security Audit

• no new dependencies, authentication, secret handling, filesystem access, path parsing, or command execution
• no new IPC channel; the focused-window path retains the existing ui:appMenuPaste message
• the native fallback does not read clipboard contents and delegates only the standard paste: selector to the macOS first responder
• the fallback is runtime-gated to macOS and only runs when no Orca BrowserWindow is focused, preventing double routing

Notes

• Fixes [Bug]: Cmd+V does not paste into macOS native open/save dialogs #12640
• the change is macOS-specific by design; Linux and Windows retain the previous no-focused-window behavior
• upstream PR Checks currently require maintainer approval before fork CI jobs can run

[coderabbitai]

📝 Walkthrough

Walkthrough

The paste menu handler now sends ui:appMenuPaste when a focused window exists. Without a focused window, macOS invokes Menu.sendActionToFirstResponder('paste:'). Linux and Windows do not invoke the native responder action. Tests mock the Electron API, reset mocks, restore spies, and cover each routing case.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The implementation restores native macOS responder-chain paste and preserves focused-window paste behavior required by issue #12640.
Out of Scope Changes check	✅ Passed	The code and tests are limited to paste-menu behavior and directly support the linked macOS dialog regression.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly identifies the macOS native dialog paste fix, which is the main change in the pull request.
Description check	✅ Passed	The description covers the user-visible change, testing, AI review, security audit, platform behavior, and follow-up notes.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}