1Password connector setup

This page is the setup half — creating the OAuth app (or Connect/Service-Account credential) 1Password needs in its own console and getting its client id and secret into this deployment. Authorising a connection afterwards is the Authenticate control on the plugin sheet, which is what actually sends you to 1Password.

The connector is read-only, and cannot return a secret. Three tools — onepassword.list_vaults, onepassword.list_items, onepassword.get_item — every one tagged read, and none of their results carries a field value: only vault names, item titles, categories and URLs, and field names and kinds. There is no tool that could hand a password back to a bot, and no write tool at all — that absence is structural, not a missing feature (packages/connectors/src/onepassword.ts's own header): a tool result is shown to the model by definition, and a value the model has already read cannot be un-read.

1. Create the credential in 1Password's own console

1Password's own developer console is where you create this credential — 1Password's Connect or Service-Account offering, under your own account, never Botseon's. The exact console steps are not yet confirmed here (packages/connectors/src/onepassword.ts flags its base URL and credential kind as unverified, pending the vendor research this connector still owes) — follow 1Password's own current documentation for issuing a Connect/Service-Account credential scoped to the vaults you want this deployment to read, rather than this page inventing console steps it cannot verify.

Whatever form the credential takes, enter it through the same command every other connector uses (step 2): if 1Password's flow is a classic OAuth redirect, paste the redirect URL from docs/connectors/README.md into its console the same way the other pages describe —

http://127.0.0.1:3000/api/oauth/onepassword/callback

— and copy the client id and secret it gives you back. If it instead issues a token directly with no redirect step, --auth-url/--token-url below still need a confirmed pair of URLs before this connector can be wired up end to end; that confirmation is this page's own open item, not something to guess at here.

1a. The bot's own service account (no console step)

A member who connects a bot from the desktop app does not need step 1 at all. The app runs the vendor's signed op command-line tool on the member's own machine (ADR 0023) to create a vault for that bot and a service account that may only read items in that vault and expires; the service-account token is the one thing it sends to this deployment. A token that begins ops_ is read through the vendor's JavaScript SDK (@1password/sdk, a dependency of @botseon/connectors), because service accounts have no REST API; every other token is read from a Connect server as below. Nothing for the operator to configure: the worker needs outbound HTTPS to the member's 1Password sign-in domain, which the SDK reaches itself.

The nightly connector-live run reads a real test account through this exact path (packages/connectors/src/onepassword.live.test.ts); setting that account up is docs/operations/connector-live-setup/onepassword.md.

2. Scopes

The two checklist strings this connector's tools need, read-only (F-PLUG-1: minimum scopes per capability):

• vault:read — list vaults.
• item:read — list and read items (names and field names only, never a field value).

3. Enter the app

One command, with the client secret on standard input — there is no flag that takes it and no environment variable that holds it (see docs/connectors/README.md):

printf %s "$CLIENT_SECRET" | botseon oauth-app set \
  --org <organisation id> --slug onepassword \
  --client-id <the client ID from step 1> \
  --auth-url <1Password's confirmed authorisation URL> \
  --token-url <1Password's confirmed token URL> \
  --configured-by <your user id>

It stores the secret encrypted and prints the redirect URL from step 1 back, so you can check the two match. botseon oauth-app show --org <organisation id> --slug onepassword says whether an app is configured and under which client id; nothing prints the secret back.

Never put either value in a bot's description, a memory, or anywhere else a model reads as ordinary text.