feat(sdk): delete dir support in delete tool

[Nishitha M (imnishitha)]

The filesystem delete tool only removed single files and rejected directories, so clearing a directory (e.g. a subagent's working dir) meant one tool call per file and left the empty directories behind. This makes delete remove directories recursively, renames the tool from delete_file to delete, and makes the permission layer treat a recursive delete as a single all-or-nothing operation over the whole subtree.

What changed:

• FilesystemBackend.delete now removes directories recursively (shutil.rmtree). Symlinks are removed as links, never followed into their target.
• Renamed the tool delete_file to delete (the arg is still file_path).
• delete maps to the write operation. For a directory target, the tool expands the subtree and checks write on the target and every descendant; if any path is denied, the entire delete is refused and nothing is removed (all-or-nothing).
• delete is now registered for interrupt-mode permissions (bulk scope), so an interrupt rule on any path inside the target fires before the delete runs. It was previously absent, so interrupt rules never applied to deletes.

Why all-or-nothing: a recursive delete of a directory is one intent. If part of it is protected, refusing cleanly is safer and more predictable than leaving a half-deleted tree, and the agent can still delete the allowed paths explicitly.

[open-swe]

Open SWE Review found 3 potential issues.

Open in Web • View Open SWE trace

[corridor-security]

Security Issues

• Recursive delete permission bypass via empty directory omission
  The recursive delete authorization scan in FilesystemMiddleware._delete_denied_path() (and its async counterpart _adelete_denied_path()) enumerates subtree contents exclusively through backend.glob("**/*", path=target).matches. The FilesystemBackend.glob() implementation explicitly skips non-file entries (if not is_file: continue), meaning empty directories are never returned. _scan_delete_for_denied_path() then derives intermediate directories only from the file paths returned — so any empty directory in the subtree, including one that is the direct target of a deny write permission rule, is never checked. An attacker-controlled LLM agent can issue delete("/allowed/parent"), the pre-check passes (glob returns no files to check), and shutil.rmtree() then silently removes every empty denied directory under /allowed/parent.

[Eugene Yurtsev (eyurtsev)]

Strategy makes sense, let's pull the function to out of the class namespace and add exhaustive unit tests to check for the various edge cases

[open-swe]

Open SWE Review found 2 potential issues.

Open in Web • View Open SWE trace

[corridor-security]

Security Issues

• Uncontrolled Resource Consumption
  The new recursive StoreBackend.delete() path (and its async twin adelete()) calls _search_store_paginated() / _asearch_store_paginated(), which accumulates every page of the entire namespace into an unbounded in-memory list before filtering by the requested prefix. These helpers have no maximum item/byte cap and no timeout guard. Because the delete tool is exposed as a LangGraph tool through FilesystemMiddleware — callable by any agent that receives user input — an attacker (or a prompt-injected agent) can trigger delete("/") or a similarly broad path and force the server to load the entire namespace into memory before attempting the deletions. The async variant is equally affected. All other methods that call _search_store_paginated() (e.g. grep, glob) share the same unbounded-scan pattern, but delete additionally issues a single massive batch() call proportional to the number of keys found.

Recommendation

• Avoid full namespace scans for delete. Use key-prefix queries if the store backend supports them, or stream pages with strict maximum item/byte limits and delete in bounded batches.
• Reject overly broad recursive deletes (e.g. /) at the schema or validation layer unless explicitly approved by a permission rule.
• Add a hard cap (e.g. 10 000 items) inside _search_store_paginated() / _asearch_store_paginated() so that all callers are protected.

[corridor-security]

The recursive delete path loads the entire namespace before filtering keys for the requested prefix:

items = self._search_store_paginated(store, namespace)
to_delete = expand_delete_keys((str(item.key) for item in items), file_path)

_search_store_paginated() (store.py:376) accumulates every page into all_items: list[Item] with no maximum item or byte cap. For a namespace with N items this runs ceil(N/100) round-trips to the store and allocates O(N) heap objects before a single key is deleted. The subsequent store.batch([PutOp(..., None) for key in to_delete]) then issues all N deletions in one unbounded request with no chunking or back-pressure.

The delete tool is exposed as a LangGraph StructuredTool callable by any agent that processes user messages. validate_path() accepts / as a valid path (it only blocks traversal sequences), so an attacker — or a prompt-injected agent — can call delete("/") to trigger a full-namespace scan and wipe. No rate-limiting, no max-items guard, and no timeout exist at any layer in the delete path. The async variant (adelete(), store.py:742) is identically affected.

Remediation:

1. Add a hard cap (e.g. MAX_SCAN_ITEMS = 10_000) inside _search_store_paginated() and _asearch_store_paginated() that raises an exception if the accumulator exceeds the limit — this protects all callers, not just delete.
2. For delete specifically, use a prefix-aware store query (pass a filter/query to store.search()) so only matching keys are fetched rather than the entire namespace.
3. Chunk to_delete into bounded batches (e.g. ≤ 500 keys per store.batch() call) with optional yield points for async.
4. Reject delete paths of / or other root-level broad paths at the schema or validate_path() layer unless an explicit permission rule approves them.

Attack Path

1. Attacker sends an HTTP POST to the LangGraph server (e.g. /threads/{thread_id}/runs) with a user message instructing the agent to delete all files, e.g. "Delete everything under /" or via a prompt-injection payload in agent-readable content.

2. The LangGraph agent calls the delete tool with file_path="/".

3. FilesystemMiddleware delete wrapper (filesystem.py:1303/1342) calls validate_path("/") — passes (no traversal sequences).

4. _find_delete_deny_patterns() returns empty list (no deny rules configured by default); execution continues.

5. StoreBackend.delete("/") (store.py:717) calls _search_store_paginated(store, namespace) (store.py:734), entering an unbounded loop that fetches all N items in pages of 100 and accumulates them in memory.

6. expand_delete_keys(...) returns every key (all start with /).

7. store.batch([PutOp(namespace, key, None) for key in to_delete]) deletes all N keys in one request (store.py:739).

8. Attack can be repeated concurrently across threads to compound CPU/memory exhaustion.

For more details, see the finding in Corridor.

Provide feedback: Reply with whether this is a valid vulnerability or false positive to help improve Corridor's accuracy.

[Eugene Yurtsev (eyurtsev)]

Nishitha M (@imnishitha)

Optimizations that we can follow up with:

• Make sure that we have async implementations for grep, glob, ls (agrep, aglob, alas)

• Make sure that we don't eagerly load more information than we need. Pagination is OK but we don't need to load all pages into memory for things like grep, glob, ls

• When not needed we can work with keys only for glob and ls we only need the key not the value. (although full optimization would require changing how the store works in langgraph, and it's likely not that much of a high priority right now.)

• We want to be able to terminate glob/grep/ls early if there are too many results (this is not just for StoreBackend, but for all backends and would require modifying the schema of grep,glob and ls return type to accommodate some information indicating that that the result was truncated due to too many matches. (And ask the agent in the tool message to narrow down its search). cc Sydney Runkle (@sydney-runkle)

[Eugene Yurtsev (eyurtsev)]

None -> value=None

And i'd document that this does a deletion?