Stale server-info files can make later action invocations reuse a dead Responses proxy

Summary

Check Responses API proxy status currently treats any non-empty server-info file as proof that the Responses API proxy is still running.

The proxy's server-info format already includes both port and pid, but the action only checks -s "$SERVER_INFO_FILE". If the proxy exits unexpectedly while the JSON file remains, a later codex-action invocation in the same GitHub run skips proxy startup and reuses the stale port.

Reproduction

1. Run openai/codex-action with an API key so the proxy writes $CODEX_HOME/$GITHUB_RUN_ID.json.
2. Terminate the codex-responses-api-proxy process without deleting its server-info file, or reproduce any proxy crash after startup.
3. Invoke openai/codex-action again in the same run with the same Codex home.

Current status logic is:

if [ -s "$SERVER_INFO_FILE" ]; then
  echo "Responses API proxy already appears to be running (found $SERVER_INFO_FILE)."
  echo "server_info_file_exists=true" >> "$GITHUB_OUTPUT"
else
  echo "server_info_file_exists=false" >> "$GITHUB_OUTPUT"
fi

The second invocation therefore skips Start Responses API proxy. Read server info can still read the stale JSON successfully, so Codex is configured with a loopback port where no proxy is listening.

Expected behavior

A server-info file should only be reused when the process identified by its recorded pid is still alive. A missing, malformed, or dead PID should make the file stale so the action can remove it and start a fresh proxy.

Suggested fix

Move the status logic into a small testable helper that:

• returns server_info_file_exists=false when the file is absent or empty;
• parses the recorded pid from the JSON;
• on Unix, uses kill -0 to verify the process exists before reusing the file;
• removes stale server-info files before reporting false;
• preserves the current file-only behaviour on Windows if there is no reliable equivalent check in the existing Bash environment.

Impact

This is a retry/reuse reliability issue. A proxy crash can poison the server-info path for subsequent action invocations and produce a misleading downstream connection failure instead of starting a fresh proxy.

Start at the Check Responses API proxy status step and trace how it interacts with Start Responses API proxy and Read server info; the payload does not name source or test files. Exercise the helper with absent, malformed, live, and dead-PID server-info files, and verify stale files are removed, fresh proxies start, and Windows retains file-only behavior.