Make proxy config writing idempotent

[hsinchao-athena]

Summary

• Remove prior codex-action generated proxy config blocks before writing a fresh proxy config
• Preserve unrelated user config in config.toml
• Add a regression test that invokes write-proxy-config twice against the same codex-home and verifies only one provider selector/table remains

Why

Running openai/codex-action@v1 twice in the same job can currently append duplicate generated TOML keys to $CODEX_HOME/config.toml, causing the second codex exec invocation to fail with duplicate key model_provider.

Verification

• pnpm test
• ./node_modules/.bin/tsc --noEmit
• node --test test/*.test.mjs

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[techotaku39]

Hapi reproduction: pre-seeded proxy configuration still causes a duplicate key

Hapi recently encountered a related failure after applying a workaround for the protected codex-args validation introduced in openai/codex-action@v1.12.

Hapi PR #1667 was merged with a workaround that writes this configuration to a trusted CODEX_HOME/config.toml before invoking the Action:

[model_providers.codex-action-responses-proxy]
stream_max_retries = 10
stream_idle_timeout_ms = 600000

The next Hapi PR, #1668, failed with:

Error loading config.toml:
/home/runner/work/_temp/codex-home/config.toml:11:18: duplicate key

The workflow run is available here:

https://github.com/tiann/hapi/actions/runs/32555286205

CODEX_ARGS was empty in this run. The duplicate key appears because the caller pre-seeded the proxy provider section and openai/codex-action@v1.12 subsequently wrote its generated proxy configuration to the same CODEX_HOME.

This is not a second Action invocation. The existing provider section was written by the calling workflow before the Action started.

Would PR #110’s removeGeneratedProxyConfig logic handle an existing matching provider section that does not contain the # Added by codex-action. marker? If not, could the Action merge or replace the provider configuration by key, or use a separate overlay configuration?

Related reports:

• openai/codex-action#80
• Hapi #1661
• Hapi #1667
• Hapi #1668