Allow /tmp writes in the SRT sandbox for Duo Workflow
What does this MR do and why?
Fixes the SRT sandbox configuration for Duo Workflow so that LLMs can write to /tmp naturally, while protecting platform-internal files (like srt-settings.json) in a dedicated system directory that the agent cannot overwrite.
Problem: The SRT sandbox only allowed writes to ./ and /tmp/gitlab_duo_agent_platform. LLMs naturally use /tmp for scratch files, cloning repos, and other ephemeral operations. This caused fragile fallback behavior (e.g. cloning into ./ instead of /tmp).
Solution:
- Introduce
SANDBOX_SYSTEM_DIR = "/opt/.gitlab-sandbox"— a protected directory outside/tmpfor platform-internal files likesrt-settings.json. The agent is explicitly denied write access viadenyWrite. - Update
allowWriteto["./", "/tmp"]so LLMs can use/tmpnaturally. - Remove
DUO_AGENT_PLATFORM_WRITE_DIR— it conflated platform config with agent scratch space. Update env vars to use natural locations:TMPDIR="/tmp",NPM_CONFIG_CACHE="/tmp/.npm-cache",GITLAB_LSP_STORAGE_DIR="/tmp/gitlab-lsp". - Update
setup_sandbox_commandsto createSANDBOX_SYSTEM_DIRinstead.
Closes #598355 (closed)
References
- Work item: #598355 (closed)
- Original
/tmpsecurity discussion: https://gitlab.com/gitlab-org/gitlab/-/work_items/584527
Screenshots or screen recordings
N/A — backend-only change.
| Before | After |
|---|---|
allowWrite: ["./", "/tmp/gitlab_duo_agent_platform"], denyWrite: [] |
allowWrite: ["./", "/tmp"], denyWrite: ["/opt/.gitlab-sandbox"] |
How to set up and validate locally
- Checkout this branch and start your gdk
- Go to an issue and mention the duo developer. Tell it to create a file in the /tmp directory (maybe you can ask it for a nice poem to put there?)
- Check the langsmith- or session traces to see whether you can spot any errors when it tries to do this operation
- Ask it to add a new file and modify a file within
/opt/.gitlab-sandbox--> Should not work
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Thomas Schmidt