fix(deploy): the DigitalOcean installer no longer asks for a Claude token

[obasilakis]

scripts/deploy/trinity-do-create.sh asked for a Claude subscription token, and the droplet's first boot registered it and assigned it to the seeded agents. That duplicates the onboarding overlay's Connect Claude step (trinity-enterprise#582). That step is the overlay's one blocking step, and it opens on first sign-in. It accepts a subscription token or an API key, checks the credential with Anthropic before saving it, and hands it to the agents that have none.

The installer's copy was worse on every count. It was unchecked until first boot, it rejected API keys outright, and it made every operator run claude setup-token before a server even existed. It also put a second secret into user-data that the metadata service serves for the life of the machine.

What changes

• Prompts: three questions now (password ×2, region, name), plus the cost confirmation. The token prompt, its _Q quoting and its comments are gone.
• First boot: no admin login, no POST /api/subscriptions, no per-agent assign loop, no jq. The user-data carries only the admin password and the tag.
• Finish message: adds "After you sign in, Trinity asks you to connect Claude."
• Docs: PROV-014 (and PROV-013's note on what user-data holds), feature-flows/hosted-install.md, and every user doc that described the token prompt: deploying/digitalocean.md, deploying/single-server.md, deploying-trinity.md, faq/deployment-and-upgrades.md and the docs index card in user-docs/README.md. In the DigitalOcean guide, the token step and its troubleshooting rows are gone, and Step 5 now covers Connect Claude. Its success check is the install log's last line, === Trinity is ready at https://<droplet-ip> ===, which the first-boot script (set -euo pipefail) writes only after start.sh --provision succeeds.
• Not changed: whats-new/v0.9.5.md still lists the token step, because it describes the v0.9.5 installer, which asks for one.

Tests

• test_the_installer_asks_for_no_claude_credential: the real script, run against a stub doctl, reaches the end on three answers plus the confirmation. It prints no setup-token / sk-ant- prompt, and its user-data contains no /api/subscriptions. Red against the previous script, green now.
• The quoting round-trip test keeps its password and tag cases and drops the token case.
• pytest tests/unit/test_2380_*.py: 169 passed.

Not run on a real droplet yet. The script clones by tag, so the first real run is from the tag that includes this change.

Release note

The installer URL serves the script at whatever tag it is fetched from. v0.9.5 and earlier still ask for the token, and the DigitalOcean guide says so. The first release tagged after this merges ships the installer without the prompt.

Partially addresses abilityai/trinity-enterprise#622 (item 2, the token half). The admin password still travels in user-data.

🤖 Generated with Claude Code

[github-actions]

⚠️ Nightly unit-suite found regressions when this PR is merged into dev (1 of 3 seeds).

Regression details (head_sha: `1db07e6f011f2e8566ca51fa021ddae7d57ec5bf`)

Seed 12345

Backend unit-suite regression diff

Per-XML totals

Side	Path	Total	Pass	Fail	Error	Skip
base	junit-base-pr2867-12345.xml	16742	16710	1	0	31
head	junit-head-pr2867-12345.xml	16744	16709	2	1	32

❌ New failures introduced by HEAD (2)

Tests failing under HEAD that did not fail under BASE in any seed:

• [E] test_subprocess_pgroup.TestTerminateProcessGroup::test_kills_parent_and_grandchild
• [F] test_subprocess_pgroup.TestTerminateProcessGroup::test_kills_parent_and_grandchild

Legend: [F] = assertion failure, [E] = collection or fixture error.
Identity = (classname, name, kind); union taken across all input XMLs.

Reproduce locally: git merge dev && ( cd tests && python -m pytest unit/ -m "not slow" -p randomly --randomly-seed=12345 )

[github-actions]

⚠️ Live-instance suite skipped — merge conflict against dev.

Resolve by merging dev locally and pushing the result; the next nightly re-tests.

[vybe]

merge-train: ejected from today's train — rides the next one once the docs catch up. Nothing was pushed to this branch.

To be clear about why, because it isn't a criticism of the work: the coverage question passes cleanly here, and it's the best-tested PR I looked at today. test_the_installer_asks_for_no_claude_credential runs the real script as a subprocess against a stub doctl and asserts on runtime artifacts — proc.stderr and the captured user-data.sh — not on source text. I verified the red myself by swapping dev's script in: it halts at Paste the token:, so the test is red for the behaviour, not for a missing string. I also confirmed the replacement path is real and present in the pinned tag: the onboarding claude step is required: true, mounted unconditionally at Dashboard.vue:489, OSS and un-gated, and subscriptions.py:135/138-145 plus the API-key twin in settings/credentials.py do the adoption the deleted first-boot loop used to do — all present in v0.9.5. The jq removal is safe; start.sh:198 installs it during --provision.

What blocks it is drift dev created underneath the branch. docs/user-docs/guides/deploying/digitalocean.md landed via #2869 after this branched, so it isn't in your file list — and it's now the guide deploying-trinity.md sends operators to. On dev it still teaches the deleted flow:

• :17 prerequisite — "Claude Code installed … You use it to create the subscription token"
• :48-56 — "Step 3: Get your Claude subscription token" → claude setup-token
• :75 — the installer's answer list: "2. The token from Step 3."
• :103 — "There is no Connect Claude step, because the installer already connected your subscription." — exactly inverted by this PR
• :134 — the verification row tells operators tail -20 /var/log/trinity-install.log should show Claude subscription attached to agent: <name>. This PR deletes that echo, so an operator following the guide reads a successful install as a failed one.
• :150-151 troubleshooting rows for prompts that can no longer occur, and :174's summary

Same class, and these must not be lost to a "take ours" resolution during the conflict you already have: faq/deployment-and-upgrades.md:39 (dev's new DO question, still claude setup-token) and deploying-trinity.md:15 and :277.

I left this to you rather than resolving it in-train because rewriting seven passages of a user guide is real technical writing, not a merge resolution — you'd want your own wording, and :134 in particular needs a replacement success signal chosen deliberately.

There is no issue this closes, and #2380 is not it. #2380 is CLOSED and titled "record install provenance (DO Marketplace) + first-run HTTPS/VPN hardening guide" — the branch and the test_2380_* filenames inherited that number only because the script was born there. Fixes #2380 would re-open a closed, unrelated feature. I searched both trackers for this work and nothing was ever filed. The closest real owner is abilityai/trinity-enterprise#622 item 2, whose "closing looks like" wording this PR satisfies for the token half only — the admin password still travels in user-data for the droplet's lifetime, so item 2 shouldn't be ticked whole, and items 1/3/4 are untouched. Either file a fresh public type-bug/type-refactor and use Fixes #<new>, or add Partially addresses abilityai/trinity-enterprise#622 (item 2 — token half).

Two smaller things:

• The Release note in the body is stale. It reasons about whether v0.9.5-rc5 should be re-tagged, but dev has already merged fix(deploy): the DigitalOcean installer installs v0.9.5, not rc5 #2876 bumping the pin to v0.9.5, and v0.9.5 was tagged 2026-09-17. As written it would mislead whoever cuts the next release.
• The nightly unit suite and live-instance suite were both SKIPPED on this branch because of the conflict, so all-27-checks-green overstates what ran. Resolving the conflict gets you that coverage.
• Worth a line in the docs: between first boot and the operator finishing Connect Claude, the seeded fleet has no credential, so a schedule firing in that window fails. It matches the 1-Click path's behaviour, but it's new for this install path.

[vybe]

merge-train: not on the 2026-09-21 train either — carried over unfixed. Nothing was pushed to this branch.

This branch's last commit (ae461f42, 09-17) predates yesterday's ejection comment, so the findings there stand unchanged and I have not re-derived them. The docs drift dev created underneath the branch is still the blocker, and docs/user-docs/guides/deploying/digitalocean.md still teaches the deleted flow on dev today — I re-checked :17, :48, :53 and :150 directly.

One increment worth having before you start, because a full re-sweep of dev turned up two more files carrying the same drift that yesterday's note did not name, and neither is in your current file list:

• docs/user-docs/whats-new/v0.9.5.md:42 — "2. Create a Claude subscription token." inside the DO-install step list, and :46 — "your agents are signed in to Claude" as the post-install state.
• docs/user-docs/README.md:20 — the DigitalOcean card still advertises "doctl, a Claude subscription token, an optional domain".

So the full must-change set on merge is: digitalocean.md (prereq :16-17, Step 3 :48-56, the question list :72-77, the inverted :103, the success-string row :134, troubleshooting :150-151, summary :174), the three files you already touch, plus those two above, plus the internal pair feature-flows/hosted-install.md:150/158/163 and requirements/infrastructure.md:177 (PROV-014).

Also unchanged from yesterday: :134 is the only place in the repo that references the Claude subscription attached to agent: echo you delete, so it needs a deliberately chosen replacement success signal — that is the one passage I would not want to guess at on your behalf, and it is why this stays with you rather than being resolved in-train.

If any of yesterday's findings look wrong to you, say so on the thread and I will re-verify that specific point rather than leave it parked.

[obasilakis]

Addressed in 550e4af55 (merge of dev) and 1db07e6f0 (docs). The branch is mergeable again.

Docs drift

• deploying/digitalocean.md: the token prerequisite, Step 3 and its two troubleshooting rows are removed, and the remaining steps are renumbered. The installer question list is down to three. The Step 5 (sign-in) text now covers Connect Claude: token via claude setup-token or an API key, checked with Anthropic before it is saved. The Verify row for Claude points at Settings → Integrations after that step (the first-run subscription is named primary). The "What the installer does" section no longer mentions a second secret or subscription registration. A note says the v0.9.5 installer and earlier still ask for a token, because the example tag in the guide is v0.9.5.
• Success signal (:134): the last line of /var/log/trinity-install.log, === Trinity is ready at https://<droplet-ip> ===. The user-data runs under set -euo pipefail, so that line is written only after start.sh --provision exits 0. No new echo was needed.
• The conflict resolution keeps dev's new FAQ question and guide links in faq/deployment-and-upgrades.md and deploying-trinity.md (:15, :115, :277), minus the token. user-docs/README.md:20 and the single-server.md cross-link to the guide are updated too.
• feature-flows/hosted-install.md and PROV-014 already carried the no-token text on this branch. After the merge they read correctly, with no token references left.
• whats-new/v0.9.5.md is intentionally unchanged. It describes the v0.9.5 installer, which does ask for the token (git show v0.9.5:scripts/deploy/trinity-do-create.sh). The change belongs in the next release's notes.

Issue link: the body now says Partially addresses abilityai/trinity-enterprise#622 (item 2, the token half) and notes that the admin password is still in user-data. Nothing is marked as fixed.

Release note: rewritten against the v0.9.5 pin.

Nightlies: both were dispatched for this PR: unit and live-instance.

Uncredentialed window: no doc line is needed, because the seeded fleet has no schedules to fire. config/manifests/default-system.yaml omits schedules: on purpose ("a zero-credential fresh install must not accumulate failing cron executions"). The local:scout|sage|scribe template.yaml files declare none, and neither does Cornelius's upstream template.yaml. The guide already says no agent can run until Connect Claude is done.

[vybe]

merge-train: batch validated on train/20260921-1418 (#2934).