Rootless runtime fails with EPERM chown on chroot home when the runner's primary GID is below 1000 #10255

Summary

On a self-hosted runner whose user has a primary GID below 1000, the default rootless runtime fails before the agent starts:

[ERROR] Fatal error: Error: EPERM: operation not permitted, chown '/tmp/awf-XXXXXX-chroot-home'
    at Object.chownSync (node:fs)
    ... writeConfigs ...

Environment

• gh-aw v0.92.5 (AWF v0.28.62); also reproduced with gh-aw v0.91.12 (AWF v0.28.56)
• sandbox.agent.runtime unset (default docker, rootless network isolation)
• Self-hosted Ubuntu 24.04 VM runner, Docker 29.x, passwordless sudo available
• Runner identity: uid=1001(runner) gid=986(runner) groups=986(runner),27(sudo),985(docker)

Cause

getSafeHostGid() in src/host-identity.ts replaces any GID below 1000 with 1000 (validateIdNotInSystemRange). prepareChrootHomeMounts() in src/chroot-home-setup.ts then calls fs.chownSync(emptyHomeDir, 1001, 1000). A non-root process can only chown to a group it belongs to, so this fails with EPERM. The code is the same at v0.28.66 and on main.

Many self-hosted images create the runner user as a system account, so a primary GID below 1000 is common.

Workaround

sandbox.agent.runtime: docker-sudo-iptables runs AWF through sudo and avoids the failure, but it gives up the rootless default.

Suggested fix

In rootless mode, use the real process.getgid() (or skip the chown when the directory is already owned by the current user) instead of substituting 1000. Alternatively, fail with a clear preflight message naming the GID requirement. The system-range substitution makes sense when AWF runs as root through sudo, but not when it runs as the unprivileged user.