[FEATURE] .NET 9 or 10 SDK support in Claude Code for web runtime environment

Status Fixed / completed
Maintainer reply None cached
Activity 15 comments · opened Nov 14, 2025 · closed Aug 17, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Description:

The Claude Code for web runtime environment currently doesn't have the .NET 9 SDK installed, making it impossible to build .NET 9 projects.

Current behavior:

Running dotnet --version in Claude Code for web returns "command not found"
.NET 9 projects cannot be built in the Claude Code for web environment
Expected behavior:

.NET 9 SDK should be available in the runtime environment
Users should be able to build and work with .NET 9 projects directly in Claude Code for web
Context:

.NET 9 was released in November 2024 (over a year ago)
.NET 8 was previously available in the Claude Code for web environment
Many projects have already migrated to .NET 9
Request: Could you please:

Install .NET 9 SDK in the Claude Code for web runtime environment
Provide documentation about which SDK versions are available in the web environment
Share a roadmap for future SDK version updates
Workaround: Currently, users need to either downgrade their projects to .NET 8 or build locally/in CI/CD pipelines.

Thank you!

Proposed Solution

install .Net latest on agents for web claude

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

12 Comments

sandves · 9 months ago
pergradeen-oss · 9 months ago

not supported yet.

joakimriedel · 8 months ago

Just tried running Claude Code for Web and got bit by this issue. There are actually more than one issue to get .net 10 running;

1) The environment's egress proxy blocks access to builds.dotnet.microsoft.com, which is required to download the .NET SDK installer. This can be solved by adding builds.dotnet.microsoft.com to the custom host allow list. I use this script to install dotnet based on my global.json version.

#!/usr/bin/env bash
set -euo pipefail

# Find nearest global.json (current dir -> parents)
find_global_json() {
  local d="$PWD"
  while :; do
    if [ -f "$d/global.json" ]; then echo "$d/global.json"; return 0; fi
    [ "$d" = "/" ] && return 1
    d="$(dirname "$d")"
  done
}

GLOBAL_JSON_PATH="$(find_global_json || true)"
if [ -z "${GLOBAL_JSON_PATH:-}" ]; then
  echo "ensure-dotnet: no global.json found; nothing to enforce."
  exit 0
fi
echo "ensure-dotnet: using $(realpath "$GLOBAL_JSON_PATH")"

# Extract .sdk.version (prefer jq, fallback to python)
extract_version() {
  if command -v jq >/dev/null 2>&1; then
    jq -r '.sdk.version // empty' < "$GLOBAL_JSON_PATH"
  else
    python3 - "$GLOBAL_JSON_PATH" <<'PY'
import json,sys
p=sys.argv[1]
with open(p,'r',encoding='utf-8') as f:
    j=json.load(f)
print(j.get('sdk',{}).get('version',''))
PY
  fi
}
SDK_VERSION="$(extract_version)"
if [ -z "$SDK_VERSION" ] || [ "$SDK_VERSION" = "null" ]; then
  echo "ensure-dotnet: could not read .sdk.version from global.json" >&2
  exit 1
fi
echo "ensure-dotnet: target SDK = $SDK_VERSION"

# If exact version already installed and resolvable, done.
have_exact() {
  command -v dotnet >/dev/null 2>&1 && dotnet --list-sdks 2>/dev/null | awk '{print $1}' | grep -qx "$SDK_VERSION"
}
if have_exact; then
  echo "ensure-dotnet: SDK $SDK_VERSION already present."
  exit 0
fi

# Minimal deps (non-interactive); best-effort
# Check if sudo is functional (may be broken in sandboxed environments like Claude Code web)
can_sudo() {
  command -v sudo >/dev/null 2>&1 && sudo -n true 2>/dev/null
}

if command -v apt-get >/dev/null 2>&1 && can_sudo; then
  sudo DEBIAN_FRONTEND=noninteractive apt-get update -y 2>/dev/null || true
  sudo DEBIAN_FRONTEND=noninteractive apt-get install -y curl ca-certificates tar gzip jq 2>/dev/null || true
elif ! command -v curl >/dev/null 2>&1; then
  echo "ensure-dotnet: curl not found and cannot install (no sudo). Cannot proceed." >&2
  exit 1
fi

# Fetch installer
tmp="$(mktemp -d)"
trap 'rm -rf "$tmp"' EXIT
curl -fsSL https://dot.net/v1/dotnet-install.sh -o "$tmp/dotnet-install.sh"
chmod +x "$tmp/dotnet-install.sh"

# Choose install dir: per-user
INSTALL_DIR="${DOTNET_INSTALL_DIR:-$HOME/.dotnet}"
mkdir -p "$INSTALL_DIR"

# Install EXACT SDK version
echo "ensure-dotnet: installing $SDK_VERSION to $INSTALL_DIR"
DOTNET_CLI_TELEMETRY_OPTOUT=1 DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1 \
  "$tmp/dotnet-install.sh" \
    --version "$SDK_VERSION" \
    --install-dir "$INSTALL_DIR" \
    --quality ga

# Export for current process and make available to shells
export DOTNET_ROOT="$INSTALL_DIR"
export PATH="$INSTALL_DIR:$INSTALL_DIR/tools:$PATH"

PROFILE_SNIPPET='
# dotnet (installed via dotnet-install.sh)
export DOTNET_ROOT="$HOME/.dotnet"
export PATH="$HOME/.dotnet:$HOME/.dotnet/tools:$PATH"
'
grep -q 'DOTNET_ROOT=.*\.dotnet' "${HOME}/.bashrc" 2>/dev/null || echo "$PROFILE_SNIPPET" >> "${HOME}/.bashrc"

# Symlink for non-interactive shells (best-effort, only if sudo works)
if [ -x "$INSTALL_DIR/dotnet" ] && can_sudo; then
  sudo ln -sf "$INSTALL_DIR/dotnet" /usr/local/bin/dotnet 2>/dev/null || true
fi

# Verify exact version now present
if ! dotnet --list-sdks 2>/dev/null | awk '{print $1}' | grep -qx "$SDK_VERSION"; then
  echo "ensure-dotnet: expected SDK $SDK_VERSION not found after install" >&2
  exit 2
fi

echo "ensure-dotnet: SDK $SDK_VERSION ready."

2) Not possible to use "sudo" to symlink dotnet or modify PATH

3) NuGet is not accessible through the proxy

Full Claude Code validation output follows;

Executive Summary

The npm run setup script fails in the Claude Code sandbox environment due to two distinct issues:

  1. PATH configuration issue (solvable within session)
  2. Critical .NET proxy authentication bug (blocker - requires platform-level fix)

---

Issue #1: dotnet Not Found in PATH

Root Cause

The ensure-dotnet.sh script successfully installs the .NET SDK 10.0.100 to /root/.dotnet/, but the PATH modification doesn't propagate to subsequent npm commands because:

  1. The script runs as a subprocess via spawnSync() - environment changes don't propagate to parent
  2. sudo is unavailable in the sandbox, so the symlink at /usr/local/bin/dotnet cannot be created
  3. The .bashrc modification only affects new interactive shells, not the current process

Evidence

dotnet installed at: /root/.dotnet/dotnet (70KB, executable)
PATH does not contain: /root/.dotnet
Symlink /usr/local/bin/dotnet: does not exist

Solution

Workaround available: Export PATH before running setup:

export PATH="/root/.dotnet:/root/.dotnet/tools:$PATH"
export DOTNET_ROOT="/root/.dotnet"

---

Issue #2: .NET Proxy Authentication Failure (BLOCKER)

Root Cause

The sandbox environment routes all external traffic through an authenticated proxy. The proxy uses JWT-based authentication with credentials embedded in the URL:

http://username:jwt_token@21.0.0.65:15004

Critical Bug: .NET SDK on Linux does not properly send Proxy-Authorization headers when credentials are in the environment variable URL format. This is a known .NET runtime bug (#114066).

Evidence

Error: The proxy tunnel request to proxy 'http://21.0.0.65:15004/' failed with status code '401'

Note: The error shows the proxy HOST only (21.0.0.65:15004) without credentials, confirming dotnet strips/ignores them.

What Works vs What Fails

| Tool | Proxy Auth | Status |
|------|-----------|--------|
| curl | ✅ Works | Successfully authenticates |
| npm | ✅ Works | Installs packages fine |
| dotnet restore | ❌ Fails | 401 Unauthorized |
| dotnet tool restore | ❌ Fails | 401 Unauthorized |

Attempted Workarounds (All Failed)

  1. NuGet.Config with http_proxy settings - Still returns 401
  2. DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0 - No effect
  3. Unsetting env vars and using config only - Still fails
  4. Adding nuget.org to NO_PROXY - Blocks network entirely (sandbox requires proxy)

---

Recommended Solutions

For Anthropic/Claude Code Platform Team

Option A: Platform-level proxy integration for .NET

Configure the sandbox to support .NET proxy authentication. Options:

  1. Pre-configure a NuGet credential provider that handles JWT auth
  2. Add nuget.org to an allowlist that bypasses proxy
  3. Use a local NuGet cache/mirror within the sandbox

Option B: Pre-install .NET packages

Pre-restore common .NET dependencies in the sandbox image, allowing offline builds for typical projects.

Option C: Add dotnet to PATH globally

Ensure /root/.dotnet is in the system PATH for the sandbox environment if dotnet is installed.

---

Technical Details

Proxy Configuration in Sandbox

HTTP_PROXY=http://{container_id}:{jwt_token}@21.0.0.65:15004
HTTPS_PROXY=http://{container_id}:{jwt_token}@21.0.0.65:15004
NO_PROXY=localhost,127.0.0.1,*.googleapis.com,*.google.com

.NET Version

SDK: 10.0.100
Location: /root/.dotnet/

---

Conclusion

The npm run setup script cannot fully succeed in the current sandbox environment due to a fundamental incompatibility between .NET's HTTP client implementation on Linux and the sandbox's JWT-authenticated proxy. This requires a platform-level fix from Anthropic to enable .NET development workflows in Claude Code web sessions.

gusflopes · 7 months ago

Waiting for this fix. Needed for teleport

Miista · 7 months ago

I need this!

krunalm · 6 months ago

This is much needed. Please put it on priority list.

logiclabs · 6 months ago

I think I've managed to overcome this by asking claude to write a proxy to handle the auth issue with nuget, and use that for dotnet commands. Basically this is option A in the solutions above, but generated by claude in the project workspace.

It's written a simple python proxy and a bash script to replace dotnet commands. It's managing to restore, build and run .NET 10 project. I've got output of logs after starting a web app, and all looks good to me.

Miista · 6 months ago

@logiclabs how does this work exactly?

logiclabs · 6 months ago
@logiclabs how does this work exactly?

I've put this solution as a skill here: https://github.com/logiclabs/dotnet-nuget-proxy-skill. It is nearly all Claude generated and I've not had time to review the code yet. It needs a bit more testing, as I was having problems with other network calls, but if you just tell Claude to look at that repo to learn how to handle the nuget auth problem, it will add a similar solution to your own repo. I've tested this on a fresh repo with a simple .NET 10 Hello World app from scratch with Spectre Console as an external nuget package.

<img width="1251" height="580" alt="Image" src="https://github.com/user-attachments/assets/11e8d135-893c-4599-82f5-815e7c91655f" />

This proxy bridge solution isn't really new though, as I just found it was described by somebody else as a workaround https://github.com/anthropics/claude-code/issues/11897#issuecomment-3621337027

The installation instructions are wrong on the README for Claude Code Web, as it doesn't support the slash commands. To install, you can just unzip the Release zip file to your repos skill folder (.claude/skills/) and it will start using the proxy when the agent finds nuget packages don't restore.

logiclabs · 6 months ago

Will see if this can be turned into a custom Nuget credential provider, rather than using bash scripts to replace dotnet.

logiclabs · 6 months ago

I've now rebuilt the solution as a claude plugin with a .NET/C# proxy to fix the dotnet SDK install and workaround the nuget auth.

Installation details and full explanation of what's being done here: https://github.com/logiclabs/dotnet-nuget-proxy-skill

Please star the repo if it works for you to help this get picked up by the plugins marketplace directory.

After the plugin is installed, and the session hook added to your repo, a .NET build works fairly seamlessly as below:

<img width="1410" height="1692" alt="Image" src="https://github.com/user-attachments/assets/703a3b13-37ce-449d-ad6c-c0ad25f66c0e" />

<img width="1288" height="1162" alt="Image" src="https://github.com/user-attachments/assets/ba216e79-cb07-4c13-a938-1435a50f2863" />

Moarcoo · 1 month ago

Please include this! We need the most recent .NET SDK's otherwise we are not able to use the Claude web runtime at all. +1

Showing cached comments. Read the full discussion on GitHub ↗