Hosted Agent ZIP deployment fails because adduser is missing for fuse-zip
Hi, I am encountering a reproducible issue with a Microsoft Foundry Hosted Agent deployed through the Source Code ZIP deployment path. Environment: - Region: West Europe - Runtime: dotnet_10 - Target framework: net10.0 - Publish runtime: linux-x64 - Dependency resolution: bundled - Protocol: Responses 2.0.0 - API version: 2025-11-15-preview The agent version reaches the "active" status. However, the first invocation fails with: session_not_ready The relevant session logs are: Selecting previously unselected package fuse. Unpacking fuse (2.9.9-5ubuntu3) ... Selecting previously unselected package fuse-zip. Unpacking fuse-zip (0.6.0-0ubuntu3) ... dpkg: dependency problems prevent configuration of fuse: fuse depends on adduser; however: Package adduser is not installed. dpkg: error processing package fuse (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of fuse-zip: fuse-zip depends on fuse; however: Package fuse is not configured yet. dpkg: error processing package fuse-zip (--install): dependency problems - leaving unconfigured Errors were encountered while processing: fuse fuse-zip Successfully connected to container No .NET application startup logs appear after this. The application entry point does not appear to be executed, and /readiness never becomes healthy. I have already verified: A clean linux-x64 publish is used. The entry DLL is located directly at the ZIP root. The ZIP contains no nested bin, obj, or artifacts directories. All dependencies are bundled. appsettings.json, .deps.json, and .runtimeconfig.json are present. The exact published application starts successfully locally. The local /readiness endpoint returns HTTP 200. The issue is reproducible with newly deployed agent versions and new sessions. The current Foundry hosting packages and Responses Protocol 2.0 are used. The same Source Code ZIP deployment path worked successfully approximately two weeks ago. Is this a known regression in the managed source-code runtime in West Europe? Is there a workaround other than switching to the container-based deployment path? Session and request IDs can be provided privately to the Microsoft product team if required.