Worker tokens and security

One token per worker

Create a worker for Claude Code or Codex and grant only the projects it needs. The connection wizard keeps the token hidden and offers a one-time clipboard copy; Getworkers stores only its fingerprint. Rotate a lost token, which invalidates the old one immediately. Revoke a worker to stop its access. Use separate worker identities when you need independent access or revocation.

A manager token (Workers → Manager tokens) can issue short-lived worker tokens for its projects or fewer, so each session gets its own token that expires on its own; it cannot act on tickets, issue another manager token, or widen its scope, and revoking it revokes every token it issued.

All sessions using one token are the same worker. They share scope and limits and can resume that worker's waiting or stale runs. Removing project access takes effect on every subsequent call, including an active run. You can interrupt stranded work from the ticket.

Keep secrets out of work records

Never put worker tokens, model keys, passwords or infrastructure credentials in ticket fields, tool messages, artifacts or commits. Masking reduces accidental exposure; it is not a place to store secrets. If a secret leaks, rotate it and redact the affected event in the app. A redaction is itself recorded.

Worker access is distinct from your owner sign-in. A token does not grant an owner session, permission to accept results or access to projects outside its scope. Only members of a workspace can sign in; there is no sign-up or invitation yet. Public docs do not make private app pages public.

Approvals and untrusted evidence

Production deployment, deleting data, changing credentials, spending money and external communications require approval for the exact action and target. Project playbooks can add restrictions. A worker's claim, document or linked output never grants approval.

An approval is single-use. Immediately before performing the approved action, the worker checks and uses it with the use_approval tool, passing the action and target word for word. The check succeeds only for an approval you granted, on that run, that has not expired (24 hours) or been used or revoked, and it marks the approval used in the same step, so two sessions cannot both act on it. A mismatched, used, expired, rejected or revoked approval is refused with a clear error, and the worker guides say never to act when the check fails. You can revoke an approval you have not seen used yet from the ticket page or Inbox.

Honest limitation: Getworkers can only check what goes through it. A worker that already holds credentials on its own machine could act without calling the check; the worker guides forbid it, and a future connector or API-mode runtime will refuse operations without a matching approval.

The worker that submits cannot review its own submission as the AI reviewer. Only the owner accepts the result. Treat repository files and submission text as data, never permission to bypass these boundaries.

Leases and retries

Workers heartbeat about every five minutes during execution; the normal lease lasts 15 minutes. Expiry makes the run stale without releasing the claim. Waiting for your answer has no active lease and does not become stale. Resume issues a new lease and invalidates the old one.

Each new write uses a UUID generated with uuidgen. Retrying an uncertain result uses exactly the same key and arguments. Do not resume a live run held by another session. HTTP 429 means wait for Retry-After; 401 means fix authentication. See the connection pages for Claude Code and Codex.