Codex Cloud proxy breaks Databricks POST requests with `Transfer-Encoding and Content-Length`

What version of Codex is running?

Codex Cloud agent environment (no CLI version exposed)

What subscription do you have?

_No response_

Which model were you using?

_No response_

What platform is your computer?

Remote Codex Cloud runtime

What issue are you seeing?

Outbound HTTPS requests from Codex Cloud to Databricks Workspace APIs fail for POST operations with HTTP 400 Bad Message 400 and the reason text Transfer-Encoding and Content-Length.

This reproduces across different HTTP clients in the same Codex Cloud session (curl and Python requests), which suggests the failure is not specific to a Databricks SDK or CLI. It appears that the outbound proxy/request transformation layer is forwarding an invalid combination of HTTP framing headers on POST requests.

What steps can reproduce the bug?

1. From a Codex Cloud environment, obtain an OAuth token for a Databricks workspace using client credentials.
2. Send a POST request to the Databricks Workspace API, for example:

curl --http1.1 -X POST "https://<workspace-host>/api/2.0/workspace/mkdirs" \
  -H "Authorization: Bearer <access-token>" \
  -H "Content-Type: application/json" \
  -d {path:/tmp/codex-proxy-repro}\n```\n\n3. Observe the response.\n\nControl case from the same session/auth context:\n\n```bash\ncurl \"https://<workspace-host>/api/2.0/workspace/list?path=/\" \\\n  -H \"Authorization: Bearer <access-token>\"\n```\n\n### What is the expected behavior?\n\nCodex Cloud should forward outbound POST requests without introducing conflicting `Transfer-Encoding` and `Content-Length` headers. The Databricks POST request should succeed or fail based on the upstream API behavior, not HTTP framing corruption in transit.\n\n### Additional information\n\nObserved on 2026-04-07.\n\nSanitized results from the failing environment:\n\n- `curl --http1.1` POST returns HTTP `400` with body `Bad Message 400` and reason `Transfer-Encoding and Content-Length`.\n- `requests.post(..., json=...)` returns the same HTTP `400` and same reason text.\n- `GET /api/2.0/workspace/list?path=/` succeeds with HTTP `200` from the same environment using the same auth context.\n\nWhy this seems Codex-specific:\n\n- Reproduces across multiple HTTP clients, not just one library.\n- GET succeeds while POST fails.\n- The error explicitly points to invalid HTTP transfer framing rather than a Databricks application-level error.\n\nImpact:\n\nThis blocks Databricks mutation APIs from Codex Cloud, including workspace create/delete style operations and likely other POST-based endpoints.\n