This message appears when stellar can't reach the stellar-hub API. Possible reasons:
/<username> (usernames can't be changed yet)~/.config/stellar/, this is expected behaviorThis is usually not a problem - stellar will use whatever version you have cached locally.
This error means the theme doesn't exist anywhere stellar can find it:
~/.config/stellar/<author>/<theme>/ with a .toml file insideIf you're writing a custom module
and it renders as an empty string with no error anywhere, check your shell
field.
Starship doesn't pass command to the shell as an argument, it pipes it in
on stdin. So writing:
[custom.mymodule]
command = "echo hi"
when = true
shell = ["sh", "-c"]runs sh -c with nothing after the -c. sh expects the command as the
argument right after -c, finds none and errors out, which fails silently as
far as starship is concerned - the module just renders empty. The fix is to
leave -c out, so sh reads the command from stdin:
[custom.mymodule]
command = "echo hi"
when = true
shell = ["sh"]If you really want the command passed as an argument instead, set
use_stdin = false - then shell = ["sh", "-c"] works.
This class of bug - a custom module silently rendering nothing - is hard to see because starship doesn't surface an error by default. Run starship with trace logging to find out what's actually happening:
STARSHIP_LOG=trace starship promptFor the shell = ['sh', '-c'] case above, this reveals the real error:
sh: -c: option requires an argumentSTARSHIP_LOG=trace is worth reaching for any time a custom module behaves
unexpectedly, not just for this specific bug.
The messages about drafts and versions come straight from stellar-hub, so the
upload page shows the same wording as stellar publish.
This machine has no login yet, or it was revoked - from settings, or with
stellar auth logout. Run stellar auth to log in again. In CI, check that
STELLAR_TOKEN holds a token that's still listed in your settings - see
Publishing from CI.
Your stellar is newer than the hub it's talking to, usually a self-hosted or
older deployment set through STELLAR_API_URL. Publish on that hub's upload
page until it's updated.
Drafts are kept for 7 days after their last change, and are gone once
published or deleted. Run stellar publish again to start a new one - an
old --draft code or link won't come back.
Versions have to go up, compared numerically: 1.10 is newer than 1.9.
Pass a higher --version, or leave it out to get the next major version
(1.3 becomes 2.0). "Version 1.3 already exists" means the same.
There's a limit of 10 drafts at a time. Finish or delete one under Settings → Drafts.
Screenshots have to be PNG, JPEG or WebP, at most 4 MB, and at most 8000 pixels on either side (40 megapixels in total). A file that only has the right extension is refused too. Re-export it, or take a fresh screen capture.
The config isn't valid TOML: the first comes from stellar's own check before
uploading, the second from stellar-hub, and both point at the line and
column. Applying the theme locally first (stellar apply) catches the same
mistakes. Its cousins "config is empty" and "config is too long: N characters
(max 100000)" mean what they say.
Not an error. Themes with custom
modules can be published, but
everyone applying them sees a security warning first - and the
terms of use rule out harmful commands.
With --yes, or without a terminal (in CI), stellar never asks: everything
it needs has to come from a flag or a default. The message names the flag to
add. "couldn't derive a slug from …; pass --slug" and "no answer on stdin;
re-run with …" mean the same - see
Publishing from CI.
A couple of things behave differently on Windows - see how it works for the full explanation:
stellar preview is not yet supported on WindowsStill stuck? Open an issue on GitHub.