bug: find -type f doesn't enumerate files in VFS directories

[chaliy]

Description

The find builtin with -type f doesn't properly enumerate files within VFS (virtual filesystem) directories. When files are mounted in the VFS, find may not discover them during recursive directory traversal.

Reproduction

# Given VFS has files:
# /data/file1.txt
# /data/file2.txt
# /data/subdir/file3.txt

find /data -type f
# Expected:
# /data/file1.txt
# /data/file2.txt
# /data/subdir/file3.txt
# Actual: may return empty or incomplete results

Root Cause

In crates/bashkit/src/builtins/ls.rs at line 446-465, find_recursive uses ctx.fs.read_dir(path) to list directory entries. The issue may be in how the VFS read_dir implementation handles directories that were implicitly created (parent directories of mounted files) vs. explicitly created directories.

When files are mounted via the eval task's files map, intermediate directories may not have proper directory entries in the VFS, causing read_dir to return incomplete results or errors.

// line 455-465
let entries = ctx.fs.read_dir(path).await?;
let mut sorted_entries = entries;
sorted_entries.sort_by(|a, b| a.name.cmp(&b.name));

for entry in sorted_entries {
    let child_path = path.join(&entry.name);
    // ...
}

Impact

Medium — Affects any script using find to discover files in the VFS. Models work around it by using ls or hardcoding paths, but find is the standard tool for file discovery. Found in Opus and Sonnet eval runs.

Related

• See feat: find -exec not implemented #281 (find -exec not implemented)
• crates/bashkit/src/builtins/ls.rs:410-465 — find_recursive implementation
• crates/bashkit/src/fs/memory.rs — InMemoryFs read_dir implementation

Found In

Eval run 2026-02-25 (Opus and Sonnet models).

[chaliy]

Verified not reproducible. Regression tests in PR #306 confirm find -type f correctly enumerates VFS files.