Permission denied on sudo mkdir in before task for GitPod production workspace

Symptom

When a before task in .gitpod.yml attempts to create a directory under /workspace using sudo mkdir -p, the command succeeds in a workspace started locally with the gp CLI but fails with a permission denied error in a workspace launched from the GitPod dashboard (production).

Goal

Determine why the same before task behaves differently between local CLI workspaces and production hosted workspaces, focusing on the privilege and execution context of the sudo command.

Constraints and Uncertainty

The before task runs during container initialization; the local workspace may reuse a cached image and execute as the user that invoked gp, whereas production workspaces start from a freshly pulled image and may run under a different user namespace or with dropped capabilities. It is unclear whether the failure stems from the user under which the task runs, the availability of sudo, or security options (e.g., nosuid) applied to the /workspace mount in production.

• What user and group IDs does the before task execute under in a production workspace?
• Why does sudo return a permission denied error despite the image containing the binary?
• Are there any workspace configuration options (e.g., init user, sudo enablement) that affect privilege execution in the before task?