Troubleshooting¶
Fixes for the problems you are most likely to hit with Goose CLI Agent. Each entry gives the symptom, the usual cause, and what to do.
The walkthrough says "Run this demo as ubuntu"¶
Cause: you ran demo.sh as root or as another user.
Fix: run it through sudo -iu ubuntu:
"Automatic Goose first boot did not complete"¶
Cause: sushi-goose-firstboot.service has not finished or failed, so the
workspace and the ubuntu user's Goose directories may be missing.
Fix: wait for cloud-init, then check the service and its log:
cloud-init status --wait
systemctl status sushi-goose-firstboot --no-pager
sudo journalctl -b -u sushi-goose-firstboot --no-pager
Keep the instance as it is and email info@softwaresushi.com with the log. Do not include any keys.
goose configure cannot save the key¶
Cause: without GOOSE_DISABLE_KEYRING=1, Goose tries to store keys in a
desktop keyring, which is usually not available on a server instance.
Fix: set GOOSE_DISABLE_KEYRING=1 before you run goose configure, so
the key goes to ~/.config/goose/secrets.yaml:
Add the export line to ~/.bashrc so later sessions find the key.
Goose ignores the key in config.yaml¶
Cause: Goose does not read provider keys from config.yaml.
Fix: remove the key from that file and set it with goose configure or an
environment variable, as described in
Provider keys.
Goose cannot reach my model provider¶
Cause: the security group, network ACL or route table blocks outbound HTTPS.
Fix: allow outbound TCP 443 from the instance to your provider. No inbound rule is needed.
Last updated October 13, 2026 · Suggest an improvement