list subcommand panics on empty signature file

[vikvang]

Description

Running command-signatures list against an empty signatures file panics with an index-out-of-bounds instead of printing an empty table.

Steps to reproduce

1. touch /tmp/empty.json
2. command-signatures list --file /tmp/empty.json
3. Panic: index out of bounds: the len is 0 but the index is 0

Expected

An empty listing (or a clear 'no signatures found' message), not a panic.

Environment

Built from main, macOS.

[warp-factories]

Thanks for the report — the factory has picked this up and is running triage. I'll follow up on this issue with a summary and labels shortly.

Responding as Warp for OSS: View run

[warp-factories]

Triage summary

Thanks for the clear repro steps. After inspecting this repository on main, the CLI surface described here does not appear to exist, so this report does not look actionable as a bug in warpdotdev/command-signatures.

What we checked

• This repo is a library workspace, not a user-facing CLI: warp-command-signatures embeds/loads JSON completion specs, and warp-completion-metadata defines the shared types.
• The only binary target is autogenerate_powershell (command-signatures/src/bin/autogenerate_powershell.rs), which generates PowerShell cmdlet specs. It has no list subcommand and no --file flag.
• There is no argument-parsing dependency (clap/structopt) anywhere in the workspace, so there is no command-signatures list to invoke.
• Public entry points such as signature_by_name and commands (command-signatures/src/lib.rs) read embedded assets, not an external signatures file path.

Implications

command-signatures list --file /tmp/empty.json cannot be run against this repo as published — it would fail at "command not found" rather than reach the reported index-out-of-bounds panic. We found no duplicate reports.

Next step

If you hit this panic from a different tool, branch, or local prototype, please share:

1. The exact binary or crate you built (path or name)
2. The repository and commit, if not this main
3. A full panic backtrace

Happy to re-triage once that surface is identified. If the intent was to add a list utility here, that is an enhancement request rather than a panic fix.

On the ready-to-spec label

This issue was gated for spec while triage was still running. Given the findings above, the factory is holding before spec work: a spec for a fix to a non-existent subcommand would not be meaningful. @vikvang — if you'd like to proceed, please confirm which you intend, and the factory will pick it straight back up:

• Add a list command (with graceful empty-file handling) to this repo, as an enhancement; or
• The panic belongs to a different codebase and this issue should be redirected.

Labels applied: triaged, invalid. The ready-to-spec gate has been left in place untouched.

Responding as Warp for OSS: View run

[vikvang]

@warp-factory yeah @warp-agent go ahead

[warp-local-for-testing-only]

Your GitHub account is not connected to Warp. Connect it here.

[warp-factories]

Thanks @vikvang — proceeding on the enhancement reading: a list capability for this repo that handles an empty or missing signatures file gracefully instead of panicking. Spec work is starting now, and I'll link the spec PR here when it's up for your review.

Swapping invalid for enhancement to reflect that decision; the ready-to-spec gate stays as you set it.

Responding as Warp for OSS: View run

[warp-factories]

Approved and ready to merge: #394 — #394

@captainsafia has approved the implementation. All checks are green and the branch is mergeable and clean, so I've taken it out of draft; the merge itself is a maintainer's call.

What it does: adds a command-signatures list CLI and a public listing API over the embedded specs, with a bounded --file override, deterministically sorted table and --json output, and — the point of this issue — explicitly specified, non-panicking behavior for empty, whitespace-only, []/{}, malformed, oversized, deeply nested, and missing input. Each of those cases has a test asserting the exit code and that nothing panicked.

The factory's own review took three passes and fixed three problems in the untrusted-input path before hand-off: command names could forge TSV rows and columns, the parser chose its error variant by string-matching error text (so a crafted document could impersonate the limit error), and the normalizer was too narrow to stop ESC and Unicode line separators.

Spec #379 is still open separately and carries plan-approved. This issue can close once #394 lands.

Responding as Warp for OSS: View run