Remote administration could not create a bot. vole admin --remote ... account create advertised --bot in its help, but the server’s admin command only knew
--no-key and --role, so the flag was rejected as unknown option --bot. That
is the command a runner on another machine is set up with, and a runner is the
clearest case for a bot account: it is a machine, nobody signs in to it, and its
key is the only credential it needs.
The admin API now accepts --bot and creates the account with the same bot kind
as the local CLI. --bot --no-key is refused for the same reason the local CLI
refuses it: a bot has no browser sign-in, so an enrollment link would be a secret
it could never use. A bot still cannot be created as an instance admin.
The runner docs now say how the runner’s account comes into existence. A runner’s
bot holds an ordinary key for the control channel, which leases work and reports
results; the jobs it runs still get a credential minted for the run when they name
a bot with bot:, and that credential cannot lease work. The docs also note that
the runners allowlist is the trust decision, while cloning a private repository
needs a read role.
Tests: the remote admin path creates a bot, refuses the keyless form and the admin
role, and the CLI forwards --bot while reading --key locally.