fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

tokenEnv defaults to BRIDGED_WORKER_TOKEN for every profile, so opencode profiles warn about a secret they never need #158

New Issue
Closed
opened 2026-08-23 14:16:26 +02:00 by ltms · 1 comment
ltms commented 2026-08-23 14:16:26 +02:00
Owner
Copy Link
Copy Source

Split out of #156 §5.

What

fleet01 logs this at every boot:

startup secret BRIDGED_WORKER_TOKEN: MISSING (profile 'xf' tokenEnv) — the daemon will
start anyway, and this failure stays invisible until a worker actually needs it.

Profile xf has no tokenEnv in fleetd.yaml. It is an opencode profile on a free model and needs no token at all.

The name comes from FleetConfig.java:308, in Profile's compact constructor:

tokenEnv = (tokenEnv == null || tokenEnv.isBlank()) ? "BRIDGED_WORKER_TOKEN" : tokenEnv;

Every profile that leaves tokenEnv unset is given that name. requiredSecretEnvVars then reports it as a required secret that is missing.

Why it matters

The startup secret report is a good feature and I want to keep it. It exists because a missing token used to stay invisible until a worker failed hours later.

This default makes it lie. The daemon warns, at every boot, about a variable nobody configured and nothing reads. The warning text even says the failure "stays invisible until a worker actually needs it" — and no worker ever will.

A report that cries wolf at every start is worse than no report, because operators learn to skip the block it lives in. That block also carries the real warnings.

Suggested fix

A profile that does not name a tokenEnv should not have one invented for it. Either:

  • drop the default and let tokenEnv stay null, treating null as "this profile needs no token"; or
  • keep the default only for kind: claude-code profiles that are not subscription: true, which is the case it was presumably written for.

The second is closer to the existing intent, but the first is simpler and I would want to know why the default exists at all before choosing. Blame on that line would answer it.

Either way, requiredSecretEnvVars should report only what the config actually names.

Watch out for

Removing a default can change behaviour somewhere that quietly depended on it — this is the silent-default-disables-features shape in reverse. Check every reader of Profile.tokenEnv before changing it, especially the launcher paths that build a member's environment.

Tests

  • a profile with no tokenEnv produces no startup secret line
  • a profile that names one still reports set/missing correctly
  • a subscription: true profile still reports nothing (it never reads a token)
  • assert on the lines the startup report really emits, not on the map a helper returns
Split out of #156 §5. ## What `fleet01` logs this at every boot: ``` startup secret BRIDGED_WORKER_TOKEN: MISSING (profile 'xf' tokenEnv) — the daemon will start anyway, and this failure stays invisible until a worker actually needs it. ``` Profile `xf` has **no** `tokenEnv` in `fleetd.yaml`. It is an opencode profile on a free model and needs no token at all. The name comes from `FleetConfig.java:308`, in `Profile`'s compact constructor: ```java tokenEnv = (tokenEnv == null || tokenEnv.isBlank()) ? "BRIDGED_WORKER_TOKEN" : tokenEnv; ``` Every profile that leaves `tokenEnv` unset is given that name. `requiredSecretEnvVars` then reports it as a required secret that is missing. ## Why it matters The startup secret report is a good feature and I want to keep it. It exists because a missing token used to stay invisible until a worker failed hours later. This default makes it lie. The daemon warns, at every boot, about a variable nobody configured and nothing reads. The warning text even says the failure "stays invisible until a worker actually needs it" — and no worker ever will. A report that cries wolf at every start is worse than no report, because operators learn to skip the block it lives in. That block also carries the real warnings. ## Suggested fix A profile that does not name a `tokenEnv` should not have one invented for it. Either: - drop the default and let `tokenEnv` stay null, treating null as "this profile needs no token"; or - keep the default only for `kind: claude-code` profiles that are **not** `subscription: true`, which is the case it was presumably written for. The second is closer to the existing intent, but the first is simpler and I would want to know why the default exists at all before choosing. Blame on that line would answer it. Either way, `requiredSecretEnvVars` should report only what the config actually names. ## Watch out for Removing a default can change behaviour somewhere that quietly depended on it — this is the [[silent-default-disables-features]] shape in reverse. Check every reader of `Profile.tokenEnv` before changing it, especially the launcher paths that build a member's environment. ## Tests - a profile with no `tokenEnv` produces **no** startup secret line - a profile that names one still reports set/missing correctly - a `subscription: true` profile still reports nothing (it never reads a token) - assert on the lines the startup report really emits, not on the map a helper returns
ltms commented 2026-08-23 14:19:54 +02:00
Author
Owner
Copy Link
Copy Source

Duplicate of #115 (CB-612), which was filed on 2026-08-17 and is the better ticket — it names the same FleetConfig.java:308 default, proves each affected profile works without the token by reading the two launchers, and already has acceptance criteria.

I filed this without checking the open list first. Closing in favour of #115.

One thing from here worth carrying over to #115: the same false alarm now fires on fleet01 too, for profile xf, so it is not specific to the Mac's profile set. That strengthens criterion 5 there — kind: opencode profiles read their own provider credentials and arguably should never be in this check at all.

Duplicate of #115 (CB-612), which was filed on 2026-08-17 and is the better ticket — it names the same `FleetConfig.java:308` default, proves each affected profile works without the token by reading the two launchers, and already has acceptance criteria. I filed this without checking the open list first. Closing in favour of #115. One thing from here worth carrying over to #115: the same false alarm now fires on **fleet01** too, for profile `xf`, so it is not specific to the Mac's profile set. That strengthens criterion 5 there — `kind: opencode` profiles read their own provider credentials and arguably should never be in this check at all.
ltms closed this issue 2026-08-23 14:19:56 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#158
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?