No supported way to open a file in a GUI app on the user's behalf (open -e fails with procNotFound)

Summary

Attempting open -e file.txt (or open -t) to hand the user a local file in their default text editor / TextEdit fails with procNotFound: no eligible process with specified descriptor, regardless of sandbox state. This looks like a genuine capability gap rather than a permission to grant — the Bash tool's subprocess appears to have no route into the user's actual logged-in GUI/desktop session at all, so any open-style "launch an app for the user" command is a dead end.

Impact

Minor but recurring: there's no way for an agent to say "I've opened this for you to look at" for a native file the way it can hand over a file via other mechanisms. The closest alternative delivers a file to the user but doesn't open a specific native app with it.

Reproduction

1. In a Claude Code session on macOS, run open -e <path-to-a-local-file>.
2. Observe procNotFound: no eligible process with specified descriptor (or equivalent), independent of dangerouslyDisableSandbox.

Suggested fix

Either document this explicitly as unsupported (so agents stop attempting it and burning a turn on it), or provide a supported mechanism for handing a file to the user's default or chosen application.