Bug: rtk `ls` rewrite silently drops `-O` / `-@` / `-e` metadata columns, blocking macOS file-flag/xattr/ACL diagnostics

Summary

rtk's ls rewrite collapses output to a compact name size format even when the invocation includes BSD/macOS flags whose entire purpose is to surface metadata columns. The user explicitly asks for that metadata via -O (file flags), -@ (extended attributes), or -e (ACL entries); rtk rewrites the output and the requested columns vanish. There is no warning, no header, no signal that information was dropped — to a tool or an agent diagnosing a permission issue, the absence of an uchg flag or a com.apple.provenance xattr looks like ground truth.

Environment

• rtk 0.37.2
• macOS 15.6.1 (arm64)
• zsh, default Claude Code hook integration

Repro

A directory whose listing rtk decides to compress (single-file dirs are a reliable trigger; the rewrite appears to be stateful within a session, but the column-stripping behavior is consistent whenever the rewrite does fire):

$ ls -lO some/dir
config_default  76B

$ rtk proxy ls -lO some/dir
total 8
-rw-r--r--@ 1 user  staff  - 76 Apr 28 10:15 config_default

Both invocations are the same ls -lO. The rewritten output drops, all silently:

Column	Surfaced by	Dropped?
Mode bits (-rw-r--r--)	always	yes
xattr indicator (@)	-l	yes
Owner / group	-l	yes
BSD flags (uchg, -)	-O	yes
Date	-l	yes

ls -le (ACL entries) and ls -lO@e (combined) reproduce the same pattern.

Why this matters / impact

The flags -O, -@, and -e only exist on macOS ls to display metadata that the default -l does not. A user / agent reaching for them is, by definition, debugging a file-metadata problem. Stripping their output is functionally a "no" answer to a "why" question.

A concrete cost from a real session: I was diagnosing an EPERM on ~/.config/gcloud/application_default_credentials.json where cp could overwrite the file but gcloud auth application-default login could not. ls -lO (rewritten) returned name size only, suggesting nothing unusual — no flags, no @ xattr indicator. Since the rewrite was invisible, the natural conclusion was "no metadata, look elsewhere." Switching to stat -f, xattr -l, and rtk proxy ls -lO revealed the actual culprit: a com.apple.provenance xattr from macOS App Management blocking writes from a different-provenance binary. ~1 turn of agent debugging that the missing column would have prevented.

Proposed fix

Skip the rewrite (or pass ls through unchanged) when any of -O, -@, -e, or their combinations appear in argv. The plain ls, ls -l, ls -la cases that motivate the listing-compression are unaffected; metadata-inspection invocations round-trip cleanly. Optionally: also skip when the rewrite would remove columns the user asked for in any other tool's argv parsing.

If skipping is undesirable for token reasons, an alternative is to preserve the requested columns in the compressed format — e.g., compact one row per file but keep the flags / xattr-indicator / ACL columns the user explicitly asked for. The token cost is small relative to the diagnostic value.

A weaker but cheap mitigation: emit a single-line header on rewritten ls output that names the columns that were dropped, e.g. [rtk: compressed; -O/-@/-e columns omitted, use 'rtk proxy ls' for full output]. That at least makes the lossy compression discoverable.

Workaround

rtk proxy ls -lO … (and -le, -@, etc.) returns full unfiltered output, but an agent has to suspect that information was dropped to reach for it.

Related

• #1566 — rtk ls returning empty output for non-empty dirs (different bug, same family of "ls rewrite is too aggressive")
• #1604 — hook rewrite producing unparseable args for native flags (similar root cause: argv-unaware rewriting)