Syndroodocs
Version0.6.0-rc.1unpublished release candidateWebsiteGitHub

Bind a Bluesky or Threads account

Each provider reads exactly one credential source, and the CLI reads it again on every execution.

Bluesky

Create an app password in your Bluesky account settings, then export it in place of these placeholders. BLUESKY_HOST is optional and must be bsky.social.

export BLUESKY_IDENTIFIER="your-handle.bsky.social"
export BLUESKY_PASSWORD="app-password"
syndroo auth set bluesky --local --from-env

Threads

Threads reads one access token from your own app authorization. The CLI has no OAuth flow, so it never requests, refreshes or renews it.

export THREADS_ACCESS_TOKEN="user-supplied-token"
syndroo auth set threads --local --from-env

Registration verifies the account with the provider before registering it.

Credential file

One provider can read one strict JSON file instead of the environment:

{
  "schemaVersion": 1,
  "provider": "bluesky",
  "credentials": {
    "identifier": "your-handle.bsky.social",
    "password": "APP_PASSWORD_PLACEHOLDER",
    "host": "bsky.social"
  }
}
{
  "schemaVersion": 1,
  "provider": "threads",
  "credentials": { "accessToken": "USER_SUPPLIED_TOKEN_PLACEHOLDER" }
}

The file must be a plain file you own that nobody else can read, so tighten it first:

chmod 600 ./threads-credentials.json
syndroo auth set threads --local --credential-file ./threads-credentials.json

Verify and remove

syndroo auth status --local
syndroo auth status bluesky --local --verify
syndroo auth remove bluesky --local

auth status is offline, and --verify re-checks one identity over the network without changing the binding. A non-interactive registration pins the account you already checked:

syndroo auth set bluesky --local --from-env --expect-account <stable-id> --yes --no-input

Registration and verification failures are listed in the FAQ.

Next steps