Feature Request: argv passing on Linux and Windows

Disclaimer: Claude wrote this for me... But I've read it all, believe it's all accurate, and would be helpful.

Summary

The native launcher never reads its own argv. On Linux and Windows it spawns the bun process with a hard-coded two-element command line, so any arguments the OS passes to the launcher — most importantly the file path from a file association, "Open with", or a URL-scheme handler — are silently dropped before app code runs. The app has no way to learn which file it was asked to open.

Verified in v1.18.1 and still present at HEAD (through v1.18.4-beta.6): there is no std.process.argsAlloc / os.argv read anywhere in package/src/launcher/main.zig.

Reproduction

The simplest form, on either platform — build any app (electrobun build --env=stable), then run the launcher with an argument from a shell:

./launcher /tmp/example.file          # Linux
launcher.exe "C:\example.file"        # Windows

In the bun process, process.argv is exactly [<...>/bun, <...>/main.js] — the argument is gone.

The real-world path is the same drop via the OS:

• Linux: a .desktop entry with Exec=/path/to/launcher %f registered via xdg-mime — opening an associated file starts the app without the path.
• Windows: HKCU\Software\Classes\<ProgID>\shell\open\command = "C:\...\launcher.exe" "%1" — double-clicking an associated file starts the app without the path.

Where it happens

In package/src/launcher/main.zig, the child argv is constructed as exactly two hard-coded elements — { <exe_dir>/bun[.exe], <exe_dir>/../Resources/main.js } — on both Linux and Windows, and the Windows GUI-mode path builds the CreateProcessW command line as allocPrintZ("\"{s}\" \"{s}\"", .{argv[0], argv[1]}). The launcher's own arguments are never consulted on any platform.

macOS is unaffected in practice because file opens and URL schemes arrive via application:openURLs: → the open-url event instead of argv.

Why it matters

app.fileAssociations is currently macOS-only, and the docs suggest Linux/Windows users wire up associations themselves — but even a hand-written .desktop entry or registry key can't work today, because the path never survives the launcher hop. Argv forwarding is the missing primitive underneath file associations and deep links on both platforms.

Proposed fix

Read the launcher's own argv and append everything after the program name to the child argv (and to the CreateProcessW command-line string in Windows GUI mode):

launcher <args...>  →  bun main.js <args...>

App code can then pick the arguments up from process.argv (or Electrobun could later surface them via open-url for API symmetry with macOS — but plain forwarding alone unblocks everything).

Current workaround (ugly)

Since the launcher stays alive as the bun process's parent, the dropped arguments are still present in the parent's command line, and can be recovered per platform: on Linux by reading /proc/<ppid>/cmdline, on Windows via bun:ffi (NtQueryInformationProcess for the parent PID, then ReadProcessMemory to walk PEB → ProcessParameters → CommandLine). It works, but the Windows variant is Win64-offset-specific — exactly the kind of thing the launcher could make unnecessary with a few lines. Happy to submit a PR for the forwarding change if you're open to it.