-
Notifications
You must be signed in to change notification settings - Fork 3.3k
goose completion zsh generates incorrect #compdef goose-cli header, breaking autoloading #6432
Description
Describe the bug
The Zsh completion script generated by goose completion zsh contains the header #compdef goose-cli. Because the binary is named goose (not goose-cli), Zsh's autoload system ignores the completion file entirely, and tab completion fails to work even when the fpath is configured correctly.
To Reproduce
Steps to reproduce the behavior:
- Generate the Zsh completion file:
goose completion zsh > ~/.zsh/completion/_goose - Add the directory to fpath in
.zshrc:fpath=(~/.zsh/completion $fpath) - Initialize completion:
autoload -Uz compinit && compinit - Reload shell and type
goose conf+<TAB>. - Result: No completion occurs.
- Inspect the generated file:
head -n 1 ~/.zsh/completion/_goose - Observation: The first line is
#compdef goose-cli.
Expected behavior
The generated completion script should have the header #compdef goose to match the binary name, allowing Zsh to correctly associate the completion logic with the goose command.
Screenshots
(You can optionally attach that screenshot you showed me of the cat output, but the description above is likely clear enough without it.)
Please provide the following information
- OS & Arch: WSL 2 (Ubuntu) / x86_64
- Interface: CLI
- Version: (Run
goose versionin your terminal and paste it here) - Extensions enabled: None (Setup phase)
- Provider & Model: N/A (CLI issue)
Additional context
I was able to manually fix the issue by editing the generated _goose file and replacing all occurrences of goose-cli to goose e.g. the first line #compdef goose-cli to #compdef goose. After clearing the dump (rm ~/.zcompdump*) and reloading, completion worked immediately. The CLI library configuration likely defaults to goose-cli as the app name.