[BUG] EACCES: permission denied, mkdir '/plans'Details

[randomizedcoder]

Problem (one or two sentences)

When using NixOS, and LiteLLM provider, talking to local llama.cpp, I was in the planning phase, and then there was an error, which seems to have a LOT of retries. It really shouldn't retry this many times. CPU went high, and then it failed.

I guess the error handling for this error needs review.

Looking at the error I hope roo isn't really trying to create a folder in "mkdir '/plans'" We definitely don't want root writing to the root folder. So maybe the other bug is the path

Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details


Error
Error handling partial write_to_file:
EACCES: permission denied, mkdir '/plans'Details

Context (who is affected and when)

roo code user

Reproduction steps

Linux l 6.18.8 #1-NixOS SMP PREEMPT_DYNAMIC Fri Jan 30 09:32:28 UTC 2026 x86_64 GNU/Linux
Today I updated to latest nixpkgs unstable, and rebuilt.

Expected result

handle error gracefully

Actual result

caused cpu to go high retrying

Variations tried (optional)

No response

App Version

Version: 3.46.2 (d9f3683)

API Provider (optional)

LiteLLM

Model Used (optional)

qwen3-coder-30b

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis:
The bug occurs when the LLM outputs an absolute path like /plans. In WriteToFileTool.ts:

1. path.resolve(task.cwd, '/plans') returns /plans (absolute paths bypass the cwd resolution)
2. createDirectoriesForFile('/plans') tries to create a directory at system root level
3. This fails with EACCES: permission denied
4. In handlePartial(), this error occurs repeatedly with each streaming chunk, causing high CPU usage

Proposed Fix:

1. Modify WriteToFileTool.ts to handle absolute paths consistently with other tools (like SearchReplaceTool.ts and EditFileTool.ts):

   • Detect if the provided path is absolute using path.isAbsolute()
   • Convert absolute paths to relative paths using path.relative(task.cwd, absolutePath)
   • This makes /plans become plans (relative to workspace) rather than attempting root-level access

2. Add error handling in handlePartial() to wrap the createDirectoriesForFile call in try-catch to prevent repeated error messages when directory creation fails during streaming

3. Add unit tests to verify the fix handles absolute paths correctly

This approach follows the existing pattern in the codebase where other file-editing tools already handle absolute paths gracefully.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[randomizedcoder]

@roomote - Nice analysis.

I think you are saying the LLM I used returned the path for where to write the plan, but are you sure that doesn't come from Roo? I thought Roo code itself was providing the architecture phases and the planning, or maybe Roo passes this to the LLM, which the LLM then returns?

Do you have an example code examples SearchReplaceTool.ts and EditFileTool.ts, showing how the path gets manipulated to use relative paths?

[roomote]

Thanks for the questions!

Where the path comes from:
The /plans path comes from the LLM, not from Roo's code. When the LLM decides to use the write_to_file tool, it generates the tool parameters including the file path. Roo's Architect mode provides instructions/prompts to the LLM about how to plan work, but the LLM autonomously decides what path to use when calling tools. In this case, the LLM outputted /plans as an absolute path (starting with /), which is then passed directly to the WriteToFileTool.

Code examples showing path handling:

Here's how SearchReplaceTool.ts (lines 64-70) handles paths:

// Determine relative path - file_path can be absolute or relative
let relPath: string
if (path.isAbsolute(file_path)) {
    relPath = path.relative(task.cwd, file_path)
} else {
    relPath = file_path
}

EditFileTool.ts (lines 192-198) uses identical logic:

// Determine relative path - file_path can be absolute or relative
let relPath: string
if (path.isAbsolute(file_path)) {
    relPath = path.relative(task.cwd, file_path)
} else {
    relPath = file_path
}

WriteToFileTool.ts (line 31) does NOT have this handling - it just uses the path directly:

const relPath = params.path

This is the bug! When the LLM outputs /plans, the other tools would convert it to a workspace-relative path (e.g., plans), but WriteToFileTool passes it through unchanged, causing path.resolve(task.cwd, "/plans") to return /plans (absolute paths bypass the cwd resolution), leading to the permission error.

I'll proceed with implementing the fix to add the same absolute path handling to WriteToFileTool. I'll open a PR with the changes shortly.

[roomote]

Opened a PR with my attempt at addressing this: #11209

The fix adds the same absolute path handling to WriteToFileTool that already exists in SearchReplaceTool and EditFileTool. All tests pass including 2 new tests for absolute path handling. Feedback welcome!

[randomizedcoder]

@roomote

Thanks this is great

Are there other locations within the code base with similar overlooked handling of paths? It's hard to think of any time writing to "/" is a good idea. Maybe, in the interests of security and solving this issue once and for all, you can review any other places there is potentially poor handling of file paths?

Could adding a basic abstraction layer ( function ) help solve this across the entire repo efficiently and effectively?

What additional tests that would catch this condition? We need both positive and negative tests. This needs wide coverage, and ideally be table driven.

Finally, once you have completed the above items, please review the change proposal and consider what can go wrong. How can reliability be increased? How can risk be reduced?

[randomizedcoder]

Doing some manual testing.

Error handling seems to be working.

And the planning was correctly saved ( or at least it didn't error )

[randomizedcoder]

Awesome. Didn't retry forever. Not sure why Roo couldn't read this, but I suspect it's a different issue.

[cgruver]

FWIW, I am seeing this exact same issue serving a local model with Llama.cpp.

The inference server is running with the following-

llama-server --model /usr/local/models/qwen3-coder:30b --host 0.0.0.0 --port 8080 --n-gpu-layers 999 --flash-attn on --ctx-size 262144 --jinja --no-prefill-assistant --reasoning-format none