Custom codex-home fails when the target directory does not exist yet

Summary

Supplying codex-home with a path that does not already exist can make the action fail during proxy startup, because the custom path is returned without creating the directory first.

The default Codex home path is explicitly created, but the user-supplied path takes an earlier return.

Reproduction

Use a fresh path as the action's Codex home:

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    codex-home: ${{ runner.temp }}/fresh-codex-home
    prompt: Say hello.

where $RUNNER_TEMP/fresh-codex-home does not exist before the action starts.

Current resolveCodexHome behaviour is effectively:

if (inputCodexHome != null) {
  return expandTilde(inputCodexHome);
}
...
const codexHome = path.join(os.homedir(), ".codex");
await fs.mkdir(codexHome, { recursive: true });
return codexHome;

The action then derives:

$CODEX_HOME/$GITHUB_RUN_ID.json

and starts codex-responses-api-proxy --server-info <that path>. With a missing parent directory, the server-info file cannot be created and the wait step eventually reports that the proxy did not write server info.

Expected behavior

codex-home is documented as the directory to use as Codex home. The action should ensure that directory exists before any proxy/config steps attempt to write inside it, just as it already does for the default home.

For safety-strategy: unprivileged-user, a newly created custom home should be created as the configured codex-user, rather than becoming runner-owned and immediately inaccessible to Codex.

Suggested fix

After resolving the home path and before deriving/writing server state, ensure the directory exists:

• ordinary strategies: mkdir -p -- "$CODEX_HOME";
• unprivileged-user: sudo -u "$CODEX_USER" -- mkdir -p -- "$CODEX_HOME".

Existing directories should be left untouched so the action does not unexpectedly change ownership or permissions supplied by the caller.

Impact

This is setup reliability. A valid custom path currently works only if callers know to pre-create it, and the resulting failure is reported later as a proxy/server-info problem rather than as a Codex-home setup problem.

Start at the resolveCodexHome entry point and trace where the resolved path is used to derive server state before proxy startup. Ensure a missing custom directory is created with the appropriate strategy and user, while existing directories remain untouched; verify the proxy can write its server-info file for a fresh codex-home path.