v1.2.2

godrop on its own no longer tries to start a server

Typing the name of a program is a question. On a machine already running
GoDrop, the second server failed for want of a token in the shell's
environment, which read as though the first one were broken. The bare command
prints the help; the image asks for the server with CMD ["serve"], so
docker run ghcr.io/fatihbaltaci/godrop is unchanged.

Token commands look where the tokens are

godrop token list on the host reported none to somebody holding the token
setup had just printed. It reads the installation now, and says which file that
token comes from and why it has no name:

$ godrop token list

  - 1 token(s) come from GODROP_TOKENS in /home/you/.godrop/.env, including the one setup gave you
  - they have no name here; edit that file to change them, and restart the service

  - named tokens live in the container:
      docker compose --project-directory /home/you/.godrop run --rm godrop token list

godrop token create used to write into ./data on a compose host, a file the
service never reads. It now prints the command that reaches the real one, and
on a systemd or .env installation it writes into the data directory that
installation actually uses.

The README says what this is for

Coding agents can take a screenshot and cannot attach it: GitHub has no
supported API for putting an image on a pull request. Upload it here, paste the
URL. The same recipe is in the agent skill and in /llms.txt, so an agent finds
it without being told.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

docker run -d --name godrop --restart always -p 8747:8747 \
  -e GODROP_TOKENS=$(openssl rand -hex 16) \
  -v godrop-data:/data ghcr.io/fatihbaltaci/godrop:v1.2.2

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.