# Roo Code Workspace Config File Write (instance-resolved)

- **Severity:** High
- **Signature ID:** `6f4c1d92-8a3b-4e57-9c21-b0d7e5a34f18`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM01 (Prompt Injection)

## Summary

Some AI coding assistants let a compromised or manipulated agent write files without the same safety checks applied to normal project config folders. This rule flags an agent session that writes a VS Code multi-root workspace file (*.code-workspace), which can be abused to plant commands that run automatically the next time the workspace is opened.

## How the attack works

An attacker first gets malicious instructions into the agent's context, for example through a prompt injection hidden in a file, webpage, or tool output. The agent, running with auto-approved file write permissions, then spawns a process that writes or edits a .code-workspace file. Roo Code versions 3.25.23 and earlier do not apply the write protections to these files that they apply to the .vscode folder, so the attacker can insert 'tasks' or 'settings' entries into the workspace file. When the user later reopens that workspace, those entries execute automatically, giving the attacker code execution without any further action from the victim.

## Why it matters

An attacker who can inject instructions into an AI coding agent's context can achieve arbitrary code execution on the developer's machine the next time they reopen the affected project, using a file type that isn't currently protected the way other project config files are.

## What you can do

- Upgrade Roo Code past 3.25.23 if a fixed version is available, or restrict the agent's file-write permissions until it is.
- Turn off auto-approval for file writes in AI coding agents, especially for configuration files like .code-workspace, .vscode/*, and similar project settings.
- Review any .code-workspace files for unexpected 'tasks' or 'settings' entries before reopening a workspace that an agent has touched.
- Treat content pulled into an agent's context (web pages, issue trackers, file contents) as untrusted input, and audit agent sessions where writes to workspace config files occurred without an explicit user request.

## Known benign look-alikes

- Developer explicitly asking the agent to create or edit a multi-root .code-workspace file (adding folders, changing editor settings). This is a legitimate refactor task and will match the anchor stage; the rule is report-only and records the writing instance and lineage so the request can be confirmed against the transcript.
- VS Code / Cursor "Save Workspace As..." performed by the user while the editor process happens to be an ancestor of the triggering agent subprocess.
- Formatters or linters (prettier, eslint --fix, jq) rewriting the workspace JSON in place during a normal agent-assisted cleanup.
- git checkout / stash / merge run by the agent restoring a tracked .code-workspace file, and editor atomic-save temp files (*.code-workspace.tmp / ~ suffixes) which are matched deliberately.
- Project scaffolding tools (yeoman, cookiecutter, nx, turborepo generators) that emit a .code-workspace file as part of repo initialisation.

## References

- https://attack.mitre.org/techniques/T1546/
- https://attack.mitre.org/techniques/T1059/
- https://code.visualstudio.com/docs/editor/workspace-trust

---
Source: https://www.netzilo.com/threats/roo-code-workspace-config-write