Workshop retries forever when a gateway from a previous session is still running

[cprevatte]

Summary

If a gateway process from an earlier session is still running, launching the Workshop fails in a retry loop. The error does not mention the running gateway, so the cause is not discoverable from the message.

Steps to reproduce

1. Build at master and run .\target\debug\promptforge-workshop.exe (Windows 11).
2. Close the Workshop window. The gateway keeps running, which I understand is intended.
3. Later, run .\target\debug\promptforge-workshop.exe again.

What happens

The Workshop prints this repeatedly and never opens:

could not recover the local gateway: the launched gateway wrote no validated gateway discovery file within 30s

Get-Process promptforge-gateway showed a gateway from the earlier session still running (about 23 minutes of CPU time).

Workaround

Stop-Process -Name promptforge-gateway -Force

After that the Workshop launched normally.

Expected

Either the Workshop attaches to the gateway already running, or the error names the real cause, for example that a gateway is already running and holding the port.

Notes

I launched the executable directly from target\debug rather than through the installer or the tray, so this may not be a supported path. Flagging in case the attach behaviour is meant to work either way.

Windows 11, Intel Core Ultra 7, Intel Arc 140V, built from master 16 September 2026.

[cprevatte]

From claude.ai :
This is a hypothesis from reading the code, not a verified cause.
Possible cause (from reading crates/workshop/src/gateway/boot.rs, unverified)
plan_gateway attaches only when resolve(run_dir) returns Attach; any other outcome falls through to launching a sibling gateway. In this case the "could not resolve the gateway discovery file" line never appeared, so resolve seems to have returned a non-attach result cleanly rather than erroring, and the Workshop launched a second gateway.
That second gateway can't take over while the first still holds the port and the discovery file, so wait_for_launched_file_with polls for the full LAUNCH_TIMEOUT without ever seeing a validated file, and the loop repeats.
So the question may be why the still-running gateway's discovery file wasn't attachable: either validation rejecting it, or a detached gateway not keeping the file current after the Workshop that launched it exits.