mirror of
https://github.com/deepseek-ai/deepseek-harness.git
synced 2026-09-11 04:00:38 +00:00
Yichen Jiang
c44dcb7b85
The proxy guide told users a proxy could live in a project or `$DSH_HOME` `.env`. It could not: `loadLayeredEnv` refuses the four proxy names from any discovered file, as it refuses `PATH` and `NODE_OPTIONS`, and the launch fails with a pointer to `export`. That refusal is right for the invoking directory's file — it arrives with a clone, and a repository must not choose where the harness sends its traffic — and wrong for the user's own `$DSH_HOME/.env`, which already holds their API key. `readEnvLayer` now accepts `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, and `NO_PROXY` from the directory that is the Harness home, and nowhere else. `DSH_HOME` is itself bootstrap-only, so no `.env` can relocate the exemption; the CA and TLS names in the same group stay refused everywhere, since they change what is trusted rather than where traffic goes. A project `.env` that sets a proxy name still fails the launch, and its message now names the home file as the second way out. Launching from inside the home directory reads that one file as the project layer; the exemption follows the directory. The seven existing refusal cases all write to the project layer and pass unchanged. Four new cases cover the home layer accepting both casings below an exported value, the home layer still refusing `SSL_CERT_FILE`, the project layer's new message, and the same-directory launch. The guide, both package READMEs, and the two Agent Notes that stated the old rule now state this one.