fix(sdk): sandbox not-found contract and glob deny over-blocking on delete

[Nishitha M (imnishitha)]

Addresses two issues raised in review of the delete file/dir tool addition.

BaseSandbox.delete - missing paths now return a not-found error

rm -rf exits 0 even when the path does not exist, so the previous implementation returned a successful DeleteResult for paths that were never present. This diverged from the contract established by FilesystemBackend and StateBackend, which return a not-found error in that case. The fix runs test -e before rm -rf; a non-zero exit from the existence check returns Error: '<path>' not found, matching the other backends.

_find_delete_deny_patterns - glob deny rules no longer block unrelated sibling deletes

The permission check reduced every deny pattern to its non-wildcard anchor (e.g. /work/*.log → /work) and then used a subtree-overlap check, which incorrectly blocked deleting /work/notes.txt, a sibling that can never match *.log. The fix distinguishes:

• Literal patterns (no wildcards): keep the original subtree-overlap check so a deny on /work/secrets still blocks deleting the parent /work.
• Wildcard patterns with a specific anchor: block only if the target directly matches the glob (wcglob.globmatch) or the anchor sits inside the delete subtree (deleting target would recursively remove matching descendants).
• Wildcard patterns with a root anchor (/**/secrets): conservative block preserved, the pattern can match anywhere.

[open-swe]

Open SWE Review found 2 potential issues.

Open in Web • View Open SWE trace

[corridor-security]

Security Issues

• Delete permission bypass for wildcard deny rules
  The updated wildcard deny check only blocks when the delete target directly matches the deny glob or when the deny pattern's static anchor is inside the delete target. For patterns such as /work/*/secrets or /work/**/secrets, deleting /work/app does not match the glob directly and the anchor /work is not inside /work/app, so the delete is allowed even though it recursively removes /work/app/secrets, a denied path.

[corridor-security]

Security Issues

• Wildcard deny rule bypass on nested deletes
  The new delete-deny overlap logic allows nested deletes under directories that match single-component wildcard deny patterns. For example, with a deny rule like /work/secret-*, deleting /work/secret-prod/config.yml does not directly match the glob and is treated as safe because the suffix is a single component, even though the target is inside a denied wildcard-matched directory. This can let an agent/user bypass filesystem deny rules and delete protected contents.

[corridor-security]

The new single-component wildcard exemption only checks whether target itself matches pattern, then allows all descendants below the anchor when the suffix has one component:

elif PurePosixPath(target).is_relative_to(PurePosixPath(anchor)):
    anchor_parts = PurePosixPath(anchor).parts
    pattern_parts = PurePosixPath(pattern).parts
    suffix = pattern_parts[len(anchor_parts) :]
    single_filename_glob = len(suffix) == 1 and "**" not in suffix[0]
    overlaps = not single_filename_glob

This bypasses deny rules for wildcard-matched directories. For example, with a deny rule /work/secret-*, deleting /work/secret-prod/config.yml does not directly match the glob, falls into this branch, and sets overlaps = False, even though the file is inside a denied path.

Remediation: Before allowing the single-component wildcard case, check whether the immediate child under the anchor matches the deny pattern. If an ancestor such as /work/secret-prod matches /work/secret-*, treat the delete as overlapping and deny it.

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.

[codspeed-hq]

Merging this PR will improve performance by 22.9%

⚡ 1 improved benchmark
✅ 20 untouched benchmarks
⏩ 79 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	test_filesystem_init	490.4 µs	399 µs	+22.9%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing nm/delete-fixes (5dc87bd) with main (704a70d)}

Footnotes

1. 79 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩