Skip to content

Installing .net 10 preview in Codex #623

New issue
New issue
Closed as duplicate
Bug
Closed as duplicate
Installing .net 10 preview in Codex#623
Bug
Assignees
ellahathaway
Labels
Area: httpIssues related to incorrect handling of HTTP requests or responses

Description

@Haraldi-Coding
Haraldi-Coding
opened on Jul 19, 2025

I am trying to install the latest .net 10 preview version in OpenAI Codex with the provided dotnet-install.sh script. This works locally in my Debian machine, but not in Codex.

In detail here is a comprehensive description:

Working in Debian as expected (for your reference)

Doing this in on my Ubuntu machine works without any issues:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --channel 10.0 --quality preview

with result

dotnet-install: Attempting to download using aka.ms link https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz
dotnet-install: Remote file https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz size is 245519851 bytes.
dotnet-install: Extracting archive from https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz
dotnet-install: Downloaded file size is 245519851 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Installed version is 10.0.100-preview.6.25358.103
dotnet-install: Adding to current process PATH: `/root/.dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
dotnet-install: Installation finished successfully.

(Curl is version 7.88.1 on x86_64-pc-linux-gnu)

Steps to reproduce in Codex with error

Now I am trying to do the same in OpenAI Codex via:

curl -sSL https://dot.net/v1/dotnet-install.sh \
  | bash /dev/stdin --channel 10.0 --quality preview --architecture x64 --verbose

I have also tried the latest script via

curl -sSL https://builds.dotnet.microsoft.com/dotnet/scripts/v1/dotnet-install.sh \
  | bash /dev/stdin --channel 10.0 --quality preview --verbose

Take a moment, the curl command is only to show you the source of the script, downloading the script and running it locally in the console results also in the following error messages. That means, in the end I am calling in Bash

./dotnet-install.sh --channel 10.0 --quality preview --verbose
It tries to use curl (as in the source code of dotnet-install.sh you can check that this is always the first in the if).

The error is always the same:

dotnet-install:�(B Calling: machine_has curl�(B
dotnet-install:�(B Calling: get_http_header_curl https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz true�(B
dotnet-install:�(B Received response: HTTP/1.1 200 OK

dotnet-install: The aka.ms link 'https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz' is not valid: received HTTP code: 200,200.
The installed curl version is:

curl --version
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.6

Ok, I now tried manually, and all is downloading as expected:

curl -sSL https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz -o dotnet.tar.gz --verbose
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1'
* Uses proxy env variable https_proxy == 'http://proxy:8080'
* Host proxy:8080 was resolved.
* IPv6: (none)
* IPv4: 172.30.0.19
*   Trying 172.30.0.19:8080...
* Connected to proxy (172.30.0.19) port 8080
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to aka.ms:443
> CONNECT aka.ms:443 HTTP/1.1
> Host: aka.ms:443
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 OK
< date: Sat, 19 Jul 2025 21:25:48 GMT
< server: envoy
< 
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /usr/local/share/ca-certificates/envoy-mitmproxy-ca-cert.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [1556 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=aka.ms
*  start date: Jul 19 21:21:20 2025 GMT
*  expire date: Jul 19 21:22:20 2026 GMT
*  subjectAltName: host "aka.ms" matched cert's "aka.ms"
*  issuer: C=US; ST=California; L=San Francisco; O=OpenAI; CN=egress-proxy
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
} [5 bytes data]
> GET /dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz HTTP/1.1
> Host: aka.ms
> User-Agent: curl/8.5.0
> Accept: */*
> 
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [198 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [198 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/1.1 301 Moved Permanently
< content-length: 0
< server: envoy
< location: https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz
< request-context: appId=cid-v1:d94c0f68-64bf-4036-8409-a0e761bb7ee1
< x-response-cache-status: True
< expires: Sat, 19 Jul 2025 21:25:48 GMT
< cache-control: max-age=0, no-cache, no-store
< pragma: no-cache
< date: Sat, 19 Jul 2025 21:25:48 GMT
< strict-transport-security: max-age=31536000 ; includeSubDomains
< x-envoy-upstream-service-time: 46
< 
* Connection #0 to host proxy left intact
* Issue another request to this URL: 'https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz'
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1'
* Uses proxy env variable https_proxy == 'http://proxy:8080'
* Hostname proxy was found in DNS cache
*   Trying 172.30.0.19:8080...
* Connected to proxy (172.30.0.19) port 8080
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to builds.dotnet.microsoft.com:443
> CONNECT builds.dotnet.microsoft.com:443 HTTP/1.1
> Host: builds.dotnet.microsoft.com:443
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 OK
< date: Sat, 19 Jul 2025 21:25:48 GMT
< server: envoy
< 
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /usr/local/share/ca-certificates/envoy-mitmproxy-ca-cert.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [1598 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=builds.dotnet.microsoft.com
*  start date: Jul 19 21:21:20 2025 GMT
*  expire date: Jul 19 21:22:20 2026 GMT
*  subjectAltName: host "builds.dotnet.microsoft.com" matched cert's "builds.dotnet.microsoft.com"
*  issuer: C=US; ST=California; L=San Francisco; O=OpenAI; CN=egress-proxy
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
} [5 bytes data]
> GET /dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz HTTP/1.1
> Host: builds.dotnet.microsoft.com
> User-Agent: curl/8.5.0
> Accept: */*
> 
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [198 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [198 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/1.1 200 OK
< content-type: application/octet-stream
< x-ms-request-id: 00c33a57-f01e-0014-1294-f52d0f000000
< x-ms-version: 2009-09-19
< x-ms-lease-status: unlocked
< x-ms-blob-type: BlockBlob
< last-modified: Tue, 15 Jul 2025 14:04:00 GMT
< etag: 0x8DDC3A872C35638
< content-length: 245519851
< cache-control: public, max-age=493264
< date: Sat, 19 Jul 2025 21:25:48 GMT
< akamai-grn: 0.112c2017.1752960348.1e6e8543
< x-envoy-upstream-service-time: 86
< server: envoy
< 
{ [15920 bytes data]
* Connection #1 to host proxy left intact

Ok, I rewrote the dotnet-install.sh script that it now uses wget instead of curl. Uh, this does not work either:

dotnet-install:�(B Calling: get_http_header https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz true�(B
dotnet-install:�(B Calling: machine_has wget�(B
dotnet-install:�(B Calling: get_http_header_wget https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz true�(B
dotnet-install:�(B Received response:   HTTP/1.1 301 Moved Permanently

dotnet-install: The aka.ms link 'https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz' is not valid: failed to get redirect location.
Well, obviously the manual approach works as expected:

wget https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz -v
--2025-07-19 21:32:46--  https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz
Resolving proxy (proxy)... 172.30.0.3
Connecting to proxy (proxy)|172.30.0.3|:8080... connected.
Proxy request sent, awaiting response... 
301 Moved Permanently
Location: https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz [following]
--2025-07-19 21:32:47--  https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz
Connecting to proxy (proxy)|172.30.0.3|:8080... connected.
Proxy request sent, awaiting response... 
200 OK
Length: 245519851 (234M) [application/octet-stream]
Saving to: �dotnet-sdk-linux-x64.tar.gz�

          dotnet-sd   0%[                    ]       0  --.-KB/s               
         dotnet-sdk   2%[                    ]   5.03M  25.1MB/s               
        dotnet-sdk-   9%[>                   ]  22.16M  55.4MB/s               
       dotnet-sdk-l  16%[==>                 ]  37.61M  62.7MB/s               
      dotnet-sdk-li  20%[===>                ]  47.04M  58.8MB/s               
     dotnet-sdk-lin  27%[====>               ]  64.02M  63.8MB/s               
    dotnet-sdk-linu  34%[=====>              ]  81.68M  67.4MB/s               
   dotnet-sdk-linux  40%[=======>            ]  95.42M  67.2MB/s               
  dotnet-sdk-linux-  49%[========>           ] 114.82M  69.8MB/s               
dotnet-sdk-linux-x6  64%[===========>        ] 150.71M  73.7MB/s               
otnet-sdk-linux-x64  72%[=============>      ] 169.55M  75.3MB/s               
net-sdk-linux-x64.t  81%[===============>    ] 191.90M  72.3MB/s               
et-sdk-linux-x64.ta  85%[================>   ] 200.91M  70.1MB/s               
t-sdk-linux-x64.tar  93%[=================>  ] 217.95M  70.7MB/s    eta 0s     
dotnet-sdk-linux-x6 100%[===================>] 234.15M  74.4MB/s    in 3.3s    

2025-07-19 21:32:50 (71.6 MB/s) - �dotnet-sdk-linux-x64.tar.gz� saved [245519851/245519851]

WGet is version

wget --version
GNU Wget 1.21.4 built on linux-gnu.

More information for Curl

Perhaps this is because of the header information that I am getting three times a "HTTP/1.1 200 OK":

curl -I -sSL https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz
HTTP/1.1 200 OK
date: Sat, 19 Jul 2025 21:50:02 GMT
server: envoy

HTTP/1.1 301 Moved Permanently
server: envoy
location: �]8;;https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz�\https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100-preview.6.25358.103/dotnet-sdk-10.0.100-preview.6.25358.103-linux-x64.tar.gz
�]8;;�\request-context: appId=cid-v1:d94c0f68-64bf-4036-8409-a0e761bb7ee1
x-response-cache-status: True
content-length: 0
expires: Sat, 19 Jul 2025 21:50:02 GMT
cache-control: max-age=0, no-cache, no-store
pragma: no-cache
date: Sat, 19 Jul 2025 21:50:02 GMT
strict-transport-security: max-age=31536000 ; includeSubDomains
x-envoy-upstream-service-time: 75

HTTP/1.1 200 OK
date: Sat, 19 Jul 2025 21:50:02 GMT
server: envoy

HTTP/1.1 200 OK
content-type: application/octet-stream
content-md5: Z93Mal9zvdIeFJvi9mwXww==
last-modified: Tue, 15 Jul 2025 14:04:00 GMT
etag: 0x8DDC3A872C35638
x-ms-request-id: 00c35eca-f01e-0014-2094-f52d0f000000
x-ms-version: 2009-09-19
x-ms-lease-status: unlocked
x-ms-blob-type: BlockBlob
cache-control: public, max-age=491829
date: Sat, 19 Jul 2025 21:50:02 GMT
content-length: 245519851
akamai-grn: 0.2e09d817.1752961802.233d1a36
x-envoy-upstream-service-time: 94
server: envoy

This is different to my local Debian machine where I am getting: Moved Permamently --> OK.

For wget I have no clue.

Any ideas how to fix?

Activity

  1. github-project-automation
    added this to .NET Install Scriptson Jul 19, 2025
  2. github-project-automation
    moved this to Backlog in .NET Install Scriptson Jul 19, 2025
  3. github-actions
    added
    untriagedIssue is awaiting triage
    on Jul 19, 2025

  4. ellahathaway commented on Jul 23, 2025

    @ellahathaway
    ellahathaway
    on Jul 23, 2025
    Member

    [Triage]
    Can you please have the coding agent rerun the install script with --verbose and respond with the output?

    Additionally, can you describe the repro steps? Specifically, information on your machine/environment setup would be useful. It's possible that this environment has limited access to online resources, thus preventing the installation via the install script from working properly.

  5. ellahathaway
    moved this from Backlog to In Progress in .NET Install Scriptson Jul 23, 2025
  6. ellahathaway
    self-assigned this
    on Jul 23, 2025
  7. ellahathaway
    added
    needs-more-infoMore information is needed
    untriagedIssue is awaiting triage
    and removed
    untriagedIssue is awaiting triage
    on Jul 23, 2025

  8. Frulfump commented on Aug 4, 2025

    @Frulfump
    Frulfump
    on Aug 4, 2025

    Here's what I did in the beginning of June and it worked then atleast if you want to try that, haven't ran it since though.

    openai/codex-universal#13 (comment)

  9. MichaelSimons
    added the
    Bug
    issue type on Aug 20, 2025
  10. MichaelSimons
    assigned
    MichaelSimons
    and unassigned
    ellahathaway
    on Aug 21, 2025

  11. MichaelSimons commented on Aug 21, 2025

    @MichaelSimons
    MichaelSimons
    on Aug 21, 2025
    Member

    Taking ownership to investigate. I was able to repo and confirm.

  12. MichaelSimons commented on Aug 25, 2025

    @MichaelSimons
    MichaelSimons
    on Aug 25, 2025
    Member

    The underlying issue that is causing this problem is not specific to .NET 10 previews, it is affecting all versions. Here is a summary of the problem and how to possibly address it - compliments of AI.

    This issue still reproduces in a Codex shell today. The GitHub issue you linked (#623) is open and shows the exact failure signature in a Codex environment (aka.ms link ... not valid: received HTTP code: 200,200) with curl 8.5.0 behind the Codex egress proxy. The request/response trace in that issue also shows a CONNECT 200 from the proxy and OSC-8 hyperlink escape codes sprinkled into headers, both of which confuse the script’s header parsing. ([GitHub][1])

    Repro steps (Codex)

    Run these in a fresh Codex Linux session (the defaults match what’s in the issue):

    # 1) Sanity check: curl 8.5.0 and proxy are present (Codex default)
curl --version

# 2) Fetch the script
curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
chmod +x dotnet-install.sh

# 3) Try a 10.0 preview install (Codex, x64)
./dotnet-install.sh --channel 10.0 --quality preview --architecture x64 --verbose

    Expected failure (Codex):

    dotnet-install: Received response: HTTP/1.1 200 OK
dotnet-install: The aka.ms link 'https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz' is not valid: received HTTP code: 200,200.

    That’s the same signature captured in #623. ([GitHub][1])

    If you want to see what’s “really” happening under the hood in Codex, try:

    curl -sSLI -v https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz

    You’ll observe:

    • A CONNECT 200 OK from the proxy, then a 301 from aka.ms to the builds CDN, and then a final 200.
    • In some terminals, OSC-8 hyperlink escape codes get embedded around the Location: URL (looks like weird ]8;;… control characters). This is a known class of terminal behavior and shows up in curl discussions as well. ([GitHub][1])

    Why it breaks (what’s going on)

    • The install script uses a helper that parses headers from curl -I output to validate aka.ms and extract Location.
    • In Codex, the HTTP CONNECT handshake via the egress proxy returns its own 200 status line before the redirect and final response. The script ends up seeing two 200s, yielding 200,200 and failing its simple validation. (That “200,200” string is exactly what the issue shows.) ([GitHub][1])
    • Additionally, OSC-8 hyperlink sequences sometimes appear around the Location: value in terminal output (they’re invisible/clickable in capable terminals but they’re still bytes in the stream), which can break the script’s regex/grepping for the Location: header. ([GitHub][1])

    In short: the script’s header-parsing is brittle when a proxy injects an extra status line and when terminal hyperlink escape codes are present.

    Quick workarounds you can use right now

    Pick any of these; all avoid the brittle header parsing path:

    1. Let curl tell you the redirect URL (no header parsing):
    REDIR="$(curl -sS -o /dev/null -w '%{redirect_url}' \
  https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz)"
curl -fSL "$REDIR" -o dotnet-sdk.tar.gz
mkdir -p "$HOME/.dotnet" && tar -xzf dotnet-sdk.tar.gz -C "$HOME/.dotnet"
"$HOME/.dotnet/dotnet" --list-sdks

    (Using -w '%{redirect_url}' avoids CONNECT/OSC-8 parsing pitfalls entirely.) ([man7.org][2], [Linux Die][3])

    1. Use wget to resolve the redirect, then download:
    URL="$(wget -S --max-redirect=0 -O /dev/null \
  https://aka.ms/dotnet/10.0/preview/dotnet-sdk-linux-x64.tar.gz 2>&1 \
  | awk 'tolower($1)=="location:"{print $2}' | tr -d '\r')"
wget -O dotnet-sdk.tar.gz "$URL"

    The original report showed wget works cleanly in Codex. ([GitHub][1])

    1. Specify an exact version (bypasses the aka.ms resolution path the script takes for “preview” channels):
    ./dotnet-install.sh --version 10.0.100-preview.6.25358.103 --install-dir "$HOME/.dotnet" --verbose

    (Use whatever preview build you need; this option paths directly to the CDN layout. The script’s option set is documented here.) ([Microsoft Learn][4])

    Note: If you want a fully manual path instead of the script, Microsoft’s doc for scripted/manual Linux installs covers extracting to a directory and managing PATH yourself. ([Microsoft Learn][5])

    What I’d change in the script (likely fix)

    • Stop parsing curl -I output. Use curl’s structured write-out instead, e.g.:

      • curl -sS -o /dev/null -w '%{http_code}\n%{redirect_url}\n' ...
      • Or simply curl -sS -L -o /dev/null -w '%{url_effective}' ... to get the final URL.

    • If header parsing must remain, ignore CONNECT responses and strip ANSI/OSC sequences before evaluating:

      • Take the last HTTP/* status line (or the last 3xx before 200).
      • Sanitize output with something like sed -r 's/\x1B\[[0-9;]*[A-Za-z]//g; s/\x1B]8;;[^\\]*\\//g; s/\x1B]8;;\\//g' to drop color/hyperlink escapes.

    • Consider a knob to prefer wget when present in such environments.

    These adjustments would make the aka.ms resolution resilient to proxies and terminal-side hyperlinking. (OSC-8 and its impact on CLI output are well-documented; relying on -w avoids those bytes altogether.) ([GitHub][6], [man7.org][2])

    Bottom line

    • Status today: The Codex repro still fails exactly as reported; the GitHub issue remains open. ([GitHub][1])
    • Cause: Header parsing collides with proxy CONNECT 200 and possibly OSC-8 hyperlink bytes. ([GitHub][1])
    • Workarounds: Use curl’s -w redirect introspection, use wget to resolve, or pass an exact --version. ([man7.org][2], [Microsoft Learn][4])
  13. MichaelSimons
    removed their assignment
    on Aug 25, 2025

  14. baronfel commented on Aug 25, 2025

    @baronfel
    baronfel
    on Aug 25, 2025
    Member

    Of these options, the one that appeals to me most is using the structured output, assuming that the feature (and the fields we'd like to read) is present on a broad-enough set of curl versions for the platforms the scripts are used on.

  15. ellahathaway
    self-assigned this
    on Sep 3, 2025

  16. ellahathaway commented on Nov 20, 2025

    @ellahathaway
    ellahathaway
    on Nov 20, 2025
    Member

    Closing as a duplicate of #650

  17. ellahathaway
    closed this as a duplicateof The dotnet-install scripts don't handle proxy-injected redirect responses #650 on Nov 20, 2025
  18. github-project-automation
    moved this from In Progress to Done in .NET Install Scriptson Nov 20, 2025
  19. ellahathaway
    added
    Area: httpIssues related to incorrect handling of HTTP requests or responses
    and removed
    needs-more-infoMore information is needed
    untriagedIssue is awaiting triage
    on Nov 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Area: httpIssues related to incorrect handling of HTTP requests or responses

Type

Bug

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions