<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=594602) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=594602) </details> <!--IssueSummary end--> ### Summary GitLab Duo Agent Platform flows do not reliably support custom images that run as a non-root user. A recent workload job failure shows the runner checks out the repository as `root`, then the job runs as the image's non-root user and cannot access the working directory. In the failing job, the shell fails before user code runs with: ```text /bin/bash: line 199: cd: /builds/gitlab-org/cluster-integration/gitlab-agent: Permission denied ``` This appears to be the same underlying problem tracked for CI in [#444658](https://gitlab.com/gitlab-org/gitlab/-/work_items/444658): the checkout directory is owned by `root`, which breaks execution for containers that use a non-root user. Today, CI can work around this with `FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR=true`, but `agent-config.yml` does not provide a way to pass through CI variables such as `FF_*`. As a result, users cannot reliably reuse hardened or organization-standard non-root images in Duo workflows. ### Problem to solve Users want to run Duo workflows with custom images that follow container security best practices and default to a non-root user. Today, those workflows can fail during environment setup because: - the repository is cloned as `root` - the job later executes as the image's non-root user - `agent-config.yml` does not offer a supported way to configure the relevant runner behavior or feature flag workaround This makes support for non-root images unclear and effectively incomplete. ### Desired outcome Using a custom image with a non-root user in `agent-config.yml` should work without permission failures during checkout or initial directory change. A supported solution could be implemented by either: - making the execution environment handle checkout permissions correctly for non-root images, or - exposing a safe, documented way to configure the necessary runner behavior for Duo workflows ### Proposal Investigate the Duo workflow execution path for custom images with non-root users and add first-class support for this setup. At minimum, the feature should make it possible to reuse secure non-root images in `agent-config.yml` without relying on undocumented or unavailable workarounds.