rtk-ai/rtk

rtk ls returns empty output for non-empty directories (100% information loss)

Open

#1566 opened on Apr 28, 2026

View on GitHub
 (3 comments) (2 reactions) (0 assignees)Rust (48,085 stars) (2,914 forks)batch import
bugeffort-smallfilter-qualitygood first issueresolved-pending-close

Description

rtk ls returns empty output for non-empty directories (99–100% reduction = total information loss)

Summary

rtk ls <dir> produces zero file names regardless of the directory's actual content. The verbose mode reports Chars: 458 → 8 (99% reduction) as if it were a successful compression, but the output is in fact unusable for any downstream consumer (LLM agent, script, human). All ls flags I tried (-l, -la, --ultra-compact) reproduce the issue.

Reproduction

TMP=$(mktemp -d)
for n in alpha bravo charlie delta echo; do touch "$TMP/$n.dart"; done

rtk ls "$TMP/"                  # → empty
rtk ls -l "$TMP/"               # → empty
rtk ls --ultra-compact "$TMP/"  # → empty
rtk -v ls "$TMP/"               # → "Chars: 458 → 8 (99% reduction)" then empty

rtk proxy ls "$TMP/"            # → 5 lines, the actual file names

Observed

rtk ls strips out every file name. Even with -v, the only thing surviving is the compression banner — the file list itself is gone.

Expected

rtk ls should preserve at least the file/directory names. A reasonable budget could be: list the first N entries verbatim, then summarize the tail (e.g. … and 12 more). A 100% reduction on a 5-file directory is never the right answer.

Why this matters for LLM agents

The whole point of RTK is to keep enough signal in the context for an agent to make decisions. ls output is one of the most decision-load-bearing surfaces:

  • "does this file exist?"
  • "what's in this directory?"
  • "how many scripts are there?"

When rtk ls returns empty, an agent concludes the directory is empty and proceeds incorrectly. In our project (Phoenix/Alter, ~40 scripts) we hit this immediately when an agent tried to list scripts/ and concluded it was empty.

Environment

  • rtk 0.37.2
  • Darwin 25.4.0 arm64 (macOS, Apple Silicon)
  • Shell: zsh
  • Installed via brew

Suggested triage

  1. Confirm the issue reproduces on Linux as well.
  2. Check whether the regression is recent (bisect against earlier 0.3x releases).
  3. Even if compression is desired, a hard floor — "always keep at least the first N names" — would prevent the worst failure mode.

Happy to test a fix or provide more context.

Contributor guide