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.