forge -p in headless/detached use: silent death on missing API key, bunx installer 404, no stdin prompt, bare '->' parsed as flag

[KooshaPari]

Summary

Using forge 2.13.11 (forge -p "<prompt>") as detached worker lanes in a multi-agent harness against an OpenAI-compatible gateway (model="Main"). A few rough edges cause silent lane death and parsing surprises. Reporting with workarounds we found, in case they're easy fixes.

1 — forge -p child dies SILENTLY when the API key is missing from its env

If OPENAI_API_KEY (gateway key) is not present in the detached process's environment, forge -p prints the Initialize marker, then exits with zero further output and no error — looks identical to a hang. Took a while to trace to the missing key.
Ask: emit an explicit "no API key / auth failed for provider X" error to stderr before exiting, rather than dying after Initialize with no diagnostic.

2 — bunx forge / bun-shim re-runs a broken installer

Invoking via bunx forge (or the bun shim) re-triggers the installer, which tries to fetch bat/fd and 404s, so it never reaches the prompt. Calling the installed forge.exe directly skips this and works.
Ask: make the shim a no-op when forge is already installed, or don't hard-fail the run on optional-tool (bat/fd) fetch 404s.

3 — stdin prompt piping unsupported in print mode

Piping a prompt via stdin (echo "..." | forge -p) errors with No prompt provided for print mode. Only the positional arg works. For long/multiline prompts with shell-special chars, stdin would be much safer.
Ask: accept the prompt on stdin when no positional prompt is given in -p mode.

4 — bare -> in prompt PROSE mis-parsed as a CLI flag

A prompt whose prose contains a bare -> (e.g. "maps A -> B") sometimes fails with unknown option '->' and an empty log. -> inside fenced code is fine; only bare-in-prose trips it.
Ask: stop treating the positional prompt's contents as option tokens (everything after -p <prompt> should be opaque).

Environment

Windows 11, forge 2.13.11, OpenAI-compatible gateway (OmniRoute) at 127.0.0.1:20128, detached via nohup forge -p ... > log 2>&1 &.

Thanks — these are all minor but #1 (silent death on missing key) costs the most debugging time.

[KooshaPari]

Dogfood style issue from a running CC session. Ive noticed some intermittent but 2s update loop I'm aware is typically issues based on the wrapping agents do around the Forge bin. If something is wrong I will take a look and come back with proper reproduction steps & triage.