cbc worker list doesn't print a UUID, but many comands expect a UUID to identify a worker. It might be good to add a column "UUID".
% cbc -k worker list
warning: TLS certificate verification is disabled
NAME ARCH STATUS VERSION BUILD LAST SEEN
worker-01 x86_64 connected 0.1.0+g50c9587 - 2026-04-17 02:49
% cbc worker deregister -h
Deregister a worker and revoke its API key
Usage: cbc worker deregister [OPTIONS] <ID>
Arguments:
<ID> Worker ID (full UUID or unique prefix)
Options:
--config <CONFIG> Path to configuration file
-d, --debug Enable debug output (print HTTP requests/responses)
-k, --no-tls-verify Disable TLS certificate verification (for development with self-signed certificates)
-h, --help Print help
% cbc worker regenerate-token -h
Rotate a worker's API key and print the new token
Usage: cbc worker regenerate-token [OPTIONS] <ID>
Arguments:
<ID> Worker ID (full UUID or unique prefix)
Options:
--config <CONFIG> Path to configuration file
-d, --debug Enable debug output (print HTTP requests/responses)
-k, --no-tls-verify Disable TLS certificate verification (for development with self-signed certificates)
-h, --help Print help
Could we consider using the worker's name instead of their id for external referencing? Even with a rock-solid RBAC in place, it's generally best practice to avoid exposing incremental integers to the outside. Since the worker name is already enforced as unique (per 002_worker_registration.sql), this should be a safe and straightforward switch.
cbc worker listdoesn't print a UUID, but many comands expect a UUID to identify a worker. It might be good to add a column "UUID".Could we consider using the worker's
nameinstead of theiridfor external referencing? Even with a rock-solid RBAC in place, it's generally best practice to avoid exposing incremental integers to the outside. Since the worker name is already enforced as unique (per 002_worker_registration.sql), this should be a safe and straightforward switch.