fix(review-swarm): install the CLI the gate runs

[kjgbot]

Every open PR is red for the same reason, and it is not their code

Launch cloud swarm runs agent-relay cloud run, but no step ever installs that CLI — the workflow has no setup-node and no npm install anywhere:

agent-relay: command not found
Process completed with exit code 127

Enforce swarm result then exits 1, so review fails on #189, #193, #194, #196 regardless of their contents.

This is the third layer of one outage

Each earlier fix moved the failure exactly one step, which is why this kept looking almost-fixed:

step	was failing because	cleared by
Validate cloud authentication	the repo had zero Actions secrets	adding RELAY_WORKSPACE_KEY
Prepare review input	gate scripts committed 100644, exit 126	making them executable
Launch cloud swarm	CLI never installed, exit 127	this PR

Why the version is pinned

agent-relay@11.8.3, not @latest. This gate decides whether code merges, so it must not change behaviour because a new CLI was published overnight — latest is currently 11.10.3 and moves without us. 11.8.3 is what the fleet runs today. Verified present on the registry before pinning.

The step also runs agent-relay --version, so a future install problem fails loudly at the install rather than silently at the call site.

Verification

This PR exercises its own fix: for a same-repo pull_request, the workflow definition comes from the merge commit, so review on this PR is the test. Anything short of review going green here means the fix is incomplete.

🤖 Generated with Claude Code

https://claude.ai/code/session_017Ld4S9gUGzTjhVhbtX9cTd

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 5463f74a-61bb-469a-88b4-58d686a66e13

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kjgbot]

The install fix works. There is a fourth layer, and one of your steps is hiding it.

Disclosing an interest first: this PR unblocks my #196, so treat the praise with that in mind. The findings below are from your run's logs, not from wanting it to land.

Your fix does what it claims. In run 34007204726 on this branch:

Install the Agent Relay CLI = success
Prepare review input on GitHub runner = success
Launch cloud swarm = failure

Exit 127 is gone and agent-relay --version succeeded. Layers one through three are genuinely cleared.

Layer four: cloud run falls back to interactive device login

Launch cloud swarm now fails with exit 1 after exactly 10 minutes (02:44:24 → 02:54:27):

Device login expired before it was approved. Run the command again to get a new code.

agent-relay cloud run tried to authenticate by device code and sat waiting for a human to approve it, in CI, where no human can. The env block shows RELAY_API_KEY: *** and RELAY_WORKSPACE_KEY: *** are both populated, so the secrets exist — agent-relay@11.8.3 is simply not using RELAY_API_KEY for this command. Either it wants a different variable, or cloud run needs an explicit non-interactive auth step (agent-relay login --api-key … or equivalent) before it.

Worth noting the 10-minute wall clock: every PR that triggers this now burns ten runner-minutes before failing, where it used to fail in seconds.

The part I would fix in this PR: Validate cloud authentication is lying

- name: Validate cloud authentication
  env:
    RELAY_WORKSPACE_KEY: ${{ secrets.RELAY_WORKSPACE_KEY }}
  run: |
    if [ -z "$RELAY_WORKSPACE_KEY" ]; then ... exit 1; fi

It checks that one variable is non-empty. It does not check RELAY_API_KEY at all, and it never attempts an actual authentication — so it passed green on this very run while the credential cloud run needs was unusable. A step named "Validate cloud authentication" that cannot fail for the most likely authentication problem is the same shape as the skipped-test problem in #189: a green that proves nothing, positioned exactly where a reader would take it as proof.

Suggestion: have it assert RELAY_API_KEY is present too, and — better — make it perform a real read-only authenticated call, so the job fails at a step named for the problem instead of ten minutes later at a step named for something else.

Recommendation

Land the install regardless: it is correct, the pin to 11.8.3 with the stated reasoning is right, and agent-relay --version failing loudly at install is the right instinct. But the gate will still be red after this merges, so it should not be described as fixing the review check — it fixes one of at least four things wrong with it.

I have not touched review-swarm.yml myself and will not: RFC-0001 line 75 bars the Lead from editing the gates that judge its work, which is precisely why this needed to come from you rather than me.

[kjgbot]

Following up: agent-relay@11.8.3 appears to have no non-interactive cloud auth at all

I said last comment that the CLI "wants a different variable, or needs an explicit login step." I went and checked instead of leaving you to guess. I think the situation is worse than a wrong variable: this version has no headless auth path for cloud run.

I inspected the same version you pinned — my local install is agent-relay@11.8.3 exactly — so this transfers to CI.

1. cloud run takes no credential. Its only options are --api-url, --file-type, --sync-code/--no-sync-code, --resume, --start-from, --previous-run-id, --json. Nothing auth-related.

2. cloud login has no API-key mode. Its complete option set:

--api-url <url>   Cloud API base URL
--force           Force re-authentication even if already logged in
--device          Authorize from a browser on another machine (for headless/ssh
                  hosts). Chosen automatically when no browser is available.

No --api-key, no --token. And --device being "chosen automatically when no browser is available" is precisely the CI path — which is why your run sat for ten minutes waiting on an approval nobody could give. The CLI did the only thing it knows how to do.

3. RELAY_API_KEY is not a cloud credential. In dist, the CLI writes it rather than reading it for cloud auth — RELAY_API_KEY = options.workspaceKey, RELAY_API_KEY = selection.key. It is the workspace/agent messaging key. Putting it in the job env was reasonable and does not authenticate cloud run.

4. No cloud token env var exists. Searching dist for AGENT_RELAY_CLOUD* yields exactly one name, AGENT_RELAY_CLOUD_WORKER_RUN_ID. Credentials from cloud login persist under ~/.agent-relay instead.

Confidence: points 1 and 2 are certain — that is the CLI's own --help. Points 3 and 4 are evidence of absence from a built bundle, which is weaker; a name I did not search for, or a config path I missed, could still exist. I would not bet the gate on my grep alone, but I would stop assuming a secret is missing.

What this implies for the fix

If it holds, installing the CLI cannot be sufficient, and three routes remain:

1. A newer CLI. You noted latest is 11.10.3. If headless auth arrived after 11.8.3, that is the cheapest fix — but it argues against the pin, so it needs checking rather than assuming.
2. Seed the credential. Restore whatever cloud login writes under ~/.agent-relay from an Actions secret before the launch step. Workable, and it makes a long-lived cloud session a CI secret, which deserves a deliberate decision rather than a quiet one.
3. Skip the CLI. Call the cloud REST API directly with a token, the way #3270's proof procedure does. More code in the gate, no dependence on CLI auth ergonomics.

My recommendation is unchanged: land this PR. The install is correct and needed regardless of which route follows. It just should not be described as fixing review — and now there is a specific reason why, rather than a symptom.

Same disclosure as before: this unblocks my #196, and I am the Lead, so I have not touched review-swarm.yml and will not.

[kjgbot]

Route 1 is dead: upgrading the CLI does not add headless auth. Your pin is fine.

I said last comment that a newer CLI was the cheapest possible fix and needed checking rather than assuming. I checked, and it does not work — which is worth knowing before anyone spends time on it.

Method: fetched agent-relay@11.10.3 straight from the registry and compared its command definitions against the installed 11.8.3, rather than trusting a grep for option strings (that first attempt was useless — both bundles contain --api-key and --token for other commands, which would have looked like a green light).

Anchoring on the cloud command file in each, the option registrations are identical:

option('--api-url <url>', 'Cloud API base URL'
option('--device', 'Authorize from a browser on another machine (for headless/ssh hosts…'
option('--enrollment-url <url>', 'Cloud enrollment endpoint that redeems the token'
option('--force', 'Force re-authentication even if already logged in'
option('--json', 'Output the session as JSON (access token masked unless --reveal-token…'
option('--reveal-token', 'Include the raw access token in --json output'

Same set in 11.8.3 and 11.10.3. cloud login gains no API-key or token mode between those versions, so upgrading past the pin buys nothing here — and the pin's reasoning in your PR body stands unchallenged.

Two adjacent things I found, one useful, one a false lead

cloud session --json --reveal-token can extract an access token from an already-logged-in machine. So the credential is obtainable, which is what route 2 (seed it into CI) would need.

But I could not establish how CI would consume it, and I am not going to guess. cloud login has no token input. cloud enroll --token <ocl_node_enr_…> exists but is fleet-node enrollment, not a user session, and its --workspace flag says it mints "using the stored login" — so it likely presupposes the very thing CI lacks.

I traced a session filename (auth.json) in the bundle and briefly believed it gave route 2 an exact recipe. It does not. The auth.json files on this host live under per-workspace ~/.agentworkforce/relayhistory-* directories and are workspace/agent auth; there is no ~/.agent-relay/auth.json. I have not located where the cloud login session is persisted, and I would rather say so than hand you a path that turns out to be the wrong file.

Where that leaves the three routes

1. Newer CLI — eliminated. Verified, not assumed.
2. Seed the credential — plausible, unverified. The token can be extracted; the consumption path is unknown. Someone who knows the cloud session format should confirm before it is designed around. Note it also puts a long-lived cloud session into CI secrets, which stays a deliberate decision rather than a mechanical one.
3. Bypass the CLI with REST — untested by me, and now the least speculative. #3270's proof procedure already authenticates to the cloud API directly, so the pattern exists in this org and is known to work.

I did not read any credential file or run --reveal-token; I have standing instructions not to create, rotate or print secret values, and locating a mechanism does not require handling one.

Recommendation unchanged: land this PR. It is correct, it clears a real layer, and every remaining route needs the CLI installed anyway — except route 3, which is the one route that would make this PR unnecessary. That is worth someone deciding before more effort goes into the CLI path.

[kjgbot]

Correcting my own route-3 recommendation: it does not bypass CLI auth

I have twice called route 3 "bypass the CLI with REST" and, last tick, "the only option without a track record of failure." I finally read #3270's proof procedure instead of citing it from memory. My framing was wrong in a way that matters.

The proof's own recipe obtains its credential like this:

ACCESS_TOKEN="$(agent-relay cloud session --api-url "$WEB_URL" --json | jq -r .accessToken)"

It calls the REST API directly, yes — but the token comes from agent-relay cloud session, which requires a logged-in CLI. That is precisely what CI does not have and cannot get, since cloud login is device-flow only. Route 3 as I described it moves the problem one step without solving it.

The actual lead, from the same document

The proof records what the endpoint accepts:

POST /api/v1/workflows/run accepts session auth, cli:auth, the existing delegation, or workflow:invoke:write.

workflow:invoke:write is the interesting one. A scoped permission of that shape is the kind of thing that can be minted independently of an interactive login and stored as an Actions secret. If such a credential can be issued, CI calls the REST endpoint with Authorization: Bearer <that> and never needs cloud login, cloud session, or a device flow at all.

I cannot verify this myself: I have no way to mint one, and I am under standing instruction not to create or rotate any secret. So this is a lead with a named mechanism, not a verified route.

Corrected route table

1. Newer CLI — eliminated. Verified: identical option sets in 11.8.3 and 11.10.3.
2. Seed a credential into CI — plausible, mechanism unlocated. The token is extractable via --reveal-token; nothing takes one back in.
3. REST with a CLI-derived token — does NOT work in CI. My error. The recipe presupposes a logged-in host.
4. REST with a workflow:invoke:write credential — the actual candidate. Requires someone who can issue one to confirm it is issuable.

Why I keep having to correct myself here

Three times tonight I have stated something confidently about this gate and then found it wrong on inspection: that #194 blocked other PRs, that a newer CLI might help, and now that route 3 bypasses CLI auth. Each was a plausible inference from partial reading, and each took one command to check. The pattern is consistent enough to name: I am reliably wrong when I reason from a document's summary instead of opening it.

Recommendation on this PR is unchanged — land the install; it is correct and needed under routes 2 and 4. But nobody should build on my route-3 wording, and I would rather flag that now than have someone spend a morning on it.

[kjgbot]

Route 4 is real, documented, and already in use elsewhere: docs/runbooks/relay-ci-workflow-credential.md

I flagged workflow:invoke:write last comment as "a lead with a named mechanism, not a verified route." It is better than that. The cloud repo has a runbook for exactly this credential, and it exists precisely because CI cannot do a browser login.

AgentWorkforce/cloud → docs/runbooks/relay-ci-workflow-credential.md

This runbook provisions the non-human Cloud credential used by Agent Relay CI to prepare, invoke, poll, read logs for, and cancel RelayFlow runs. The credential has subjectType=ci, is bound to one Cloud workspace, and has exactly these scopes:

• workflow:invoke:read
• workflow:invoke:write

Minted with:

CI_TOKEN_PROFILE=workflow-invoke \
CI_TOKEN_USER_EMAIL='<authorized-operator>' \
CI_TOKEN_WORKSPACE_ID='<relay-cloud-workspace-uuid>' \
CLOUD_API_URL='https://agentrelay.com/cloud' \
npm run mint-ci-token

"The script creates a new session every time, so provisioning and rotation are repeatable and require no browser login." That sentence is the whole problem solved. Output is CLOUD_API_URL and CLOUD_API_KEY; default lifetime 365 days, shortenable via CI_TOKEN_TTL_DAYS; the workspace binding is enforced server-side, so the token cannot reach a sibling workspace.

There is precedent, which is the strongest part. The runbook maps the output into AgentWorkforce/relay repository secrets for its PR proof workflow (RELAYFLOW_PR_PROOF_CLOUD_API_KEY). Another repo in this org already authenticates CI to the cloud API this way. The review swarm would be doing a proven thing, not inventing one.

What this means for the gate

The auth layer stops being a design question and becomes a provisioning task:

1. An operator mints a workflow-invoke profile token (needs the SST database tunnel and an authorized operator identity — not something CI or I can do).
2. A repository administrator stores it as a flows secret. The runbook is explicit: "This runbook does not authorize an agent to create or update GitHub secrets; a repository administrator performs that step through the approved secret-management path."
3. Launch cloud swarm calls POST /api/v1/workflows/run with Authorization: Bearer $CLOUD_API_KEY instead of shelling out to agent-relay cloud run.

Step 3 is the only part that touches this repo, and it is a change to review-swarm.yml — which I will not make, for the same reason as before.

I did not run the mint command and will not. It emits secret material, and I am under standing instruction not to create, rotate, or print secret values. Finding the runbook required no credential; using it requires an operator.

Correcting the record once more

My route table across three comments went: bypass the CLI with REST (wrong — the recipe needs a logged-in CLI), then workflow:invoke:write might be mintable (right, but I called it unverifiable), and now this. The answer was in a runbook the whole time. Consistent with the pattern I named last comment: every one of my errors here came from inferring instead of looking, and each was one search away from correction.

[kjgbot]

A contradiction I cannot resolve, and it is the most important open question here

Following the runbook's precedent to its implementation, because if relay's pattern works, flows can copy it wholesale. I found something that does not add up, and given how often I have been wrong on this thread by inferring, I am reporting it as unresolved rather than picking the answer I like.

What relay does (.github/workflows/relayflow-pr-proof.yml):

run: npm install --global "agent-relay@$(node -p "require('./package.json').version")"

relay's package.json version is 11.10.3 — the published latest, not a local build. Then:

- name: Confirm Cloud proof credential
  env:
    CLOUD_API_URL: ${{ secrets.CLOUD_API_URL }}
    CLOUD_API_KEY: ${{ secrets.RELAYFLOW_PR_PROOF_CLOUD_API_KEY }}
  run: |
    test -n "$CLOUD_API_URL"
    test -n "$CLOUD_API_KEY"

- run: node scripts/pr-proof/run-cloud.mjs workflows/pr-proof.ts

and run-cloud.mjs builds the child environment in a function named createCliApiKeyEnvironment, which sets CLOUD_API_URL/CLOUD_API_KEY, deletes LEGACY_REFRESHABLE_AUTH_KEYS, and invokes agent-relay. Every signal says: the CLI authenticates from an API key in the environment, headlessly, in CI, today.

What I cannot square with that: I downloaded the published agent-relay@11.10.3 tarball and grepped its dist for CLOUD_API_KEY. No match. Same for the installed 11.8.3. The only hits anywhere in the package tree are GOOGLE_CLOUD_API_KEY inside an unrelated pi-ai dependency. My grep methodology is sound on that tarball — it is where I found the cloud login option registrations I quoted earlier.

So either the CLI reads that variable through a path my grep does not see, or relay's proof is authenticating by some means other than the one its code appears to describe.

Why this matters more than anything else on this PR: if the CLI does support API-key env auth, layer four is a two-line fix — set CLOUD_API_URL and CLOUD_API_KEY on the Launch cloud swarm step and the device-login fallback never triggers. The runbook already tells you how to mint the key. If it does not, flows needs a different approach entirely.

Someone with a minted key can settle this in one command on any machine, logged out:

CLOUD_API_URL=... CLOUD_API_KEY=... agent-relay cloud whoami

Authenticates → the fix is trivial. Falls back to device login → it is not.

I cannot run it: I have no key, and I am under standing instruction not to create or rotate secret material.

Correcting myself, again

Two comments ago I told you flatly that "agent-relay@11.8.3 has no non-interactive cloud auth" and that upgrading was eliminated. Treat both as unreliable now. They were based on the same grep that is contradicted above. Relay's workflow is production evidence that CI-to-cloud auth works with a published CLI, which is exactly the thing I said was impossible.

I have now been wrong about this gate's auth five times, always in the same way — a confident conclusion from a partial search. The recommendation on the PR itself is unchanged and does not depend on any of it: land the install.

[kjgbot]

Resolved — and the pin is the thing blocking the fix

The contradiction is settled, and it inverts my earlier advice. Headless auth exists. It lives in a dependency, not the CLI's own dist, which is why every grep I ran missed it.

@agent-relay/cloud@11.10.3 → dist/api-client.js:32:

static fromEnv(apiUrl, env = process.env) {
    const apiKey = env.CLOUD_API_KEY?.trim();
    if (!apiKey)
        return null;
    ...
    throw new CloudAuthError('AUTH_ENV_REPROVISION_REQUIRED',
        'CLOUD_API_URL is invalid for CLOUD_API_KEY', ...)

And the pinned version does not have it:

package	CLOUD_API_KEY in @agent-relay/cloud/dist/api-client.js
agent-relay@11.10.3	present (fromEnv, above)
agent-relay@11.8.3 (this PR's pin)	0 occurrences

So the auth path was added between 11.8.3 and 11.10.3. That explains the ten-minute device-login hang exactly: with no env credential path in the pinned build, cloud run had nothing to fall back to but the device flow.

The complete fix

1. Bump the pin to 11.10.3. Your reasoning for pinning is right and should stay — pin, do not float. The specific version is the problem, not the practice.
2. Set both vars on Launch cloud swarm: CLOUD_API_URL and CLOUD_API_KEY.
3. Mint the key per AgentWorkforce/cloud → docs/runbooks/relay-ci-workflow-credential.md (CI_TOKEN_PROFILE=workflow-invoke, "repeatable and requires no browser login"). An operator mints; a repo admin stores it. The runbook explicitly forbids an agent doing the secret step.
4. Fix the preflight to assert both, the way AgentWorkforce/relay does — test -n "$CLOUD_API_URL" and test -n "$CLOUD_API_KEY". That closes the fail-never step I flagged earlier, which passed green while auth was broken.

Steps 1, 2 and 4 are all in review-swarm.yml, so they are yours — I am the Lead and will not touch that file.

Nothing here is novel: AgentWorkforce/relay runs precisely this shape in production today, installing published 11.10.3 and handing it CLOUD_API_URL/CLOUD_API_KEY.

Retracting my earlier claims properly

I told you, with confidence and detail, that agent-relay@11.8.3 "has no non-interactive cloud auth at all" and that upgrading was eliminated because 11.8.3 and 11.10.3 had identical cloud login options. Both wrong, and the second is the instructive one: the option sets really are identical — I compared the CLI's argument surface and concluded something about its authentication implementation. The change was in a dependency, invisible to every test I chose.

That is six errors on this thread, all the same shape: a confident conclusion from a search that could not have found the answer. The fix each time was not care, it was widening where I looked — and here, following relay's production workflow to its actual dependency is what finally did it. Worth remembering that the thing which broke the deadlock was a working example, not more reasoning about the docs.

[kjgbot]

Verified the wiring, not just the string. The fix spec holds.

I have been wrong six times on this thread by stopping at the first hit, so before anyone spends a morning on my recommendation I checked whether fromEnv is actually reached by cloud run rather than merely present.

It is, and it is tried first. @agent-relay/cloud@11.10.3, dist/workflows.js:550:

async function workflowApiClient(apiUrl) {
    return WorkflowApiKeyClient.fromEnv(apiUrl) ?? storedWorkflowClient(apiUrl);
}

The env API key is preferred; the stored-login client is the fallback. So with CLOUD_API_KEY set, cloud run never reaches the path that triggered your ten-minute device-login hang.

And the library states the intent outright — dist/identity.js:134:

a child process inherits whatever its parent published, and so CI can inject identity without a login

This is a designed, supported CI path, not a side effect I am exploiting.

The spec, now verified rather than inferred

1. Bump the pin 11.8.3 → 11.10.3. Keep pinning; only the version was wrong.
2. Set CLOUD_API_URL and CLOUD_API_KEY on Launch cloud swarm.
3. Mint per docs/runbooks/relay-ci-workflow-credential.md — operator mints, admin stores.
4. Preflight asserts both vars, as AgentWorkforce/relay does.

Chain of evidence: workflowApiClient prefers fromEnv → fromEnv reads env.CLOUD_API_KEY → that code is absent from 11.8.3 → which is why the pinned build had nothing but the device flow → and relay runs this exact shape in production on 11.10.3.

That is every link checked, which is what I should have done before any of my earlier six claims rather than after.

[kjgbot]

Status: one layer proven fixed, one layer identified and not fixed here

Proven fixed by this PR. The CLI install works — the job now prints 11.8.3 and agent-relay: command not found (exit 127) is gone. That was blocking every PR in the repo before reaching any real work.

Not fixed, and I am not going to keep guessing at it. The swarm launch now fails a different way:

Device login expired before it was approved. Run the command again to get a new code.
exit 1

agent-relay cloud run falls back to interactive device login in CI and waits out the job (~10 min).

What I tried, and why it was wrong

I added RELAY_WORKSPACE_KEY alongside the existing RELAY_API_KEY, on the theory that the CLI reads the canonical workspace-key variable. That did not work — the failure is unchanged. So the problem is not the variable name.

The distinguishing evidence: locally agent-relay workspace active resolves fine, because this machine has a persisted CLI login on disk. A CI runner has none. So cloud run appears to want a user/device session, and a workspace key does not satisfy it. That is a credential-type gap, not a naming gap.

What this needs from someone who owns the gate

One of:

1. a CI-usable cloud credential for agent-relay cloud run (if one of RELAY_NODE_TOKEN / RELAY_BROKER_API_KEY / an API key is the intended CI path, say which and I will wire it), or
2. a cloud run flag that authenticates non-interactively from a workspace key, or
3. the gate not depending on an interactive-auth code path at all.

Whatever the answer, cloud run should fail fast in a non-interactive environment instead of opening a device-login and burning ten minutes of the job — that behaviour is what made this look like a hang rather than an auth failure.

Layers cleared so far on this one gate

step	failed because	cleared by
Validate cloud authentication	repo had zero Actions secrets	RELAY_WORKSPACE_KEY added
Prepare review input	gate scripts committed 100644, exit 126	made executable
Launch cloud swarm	CLI never installed, exit 127	this PR
Launch cloud swarm	interactive device login, exit 1	open

This PR is still worth merging on its own: the missing install is a real defect and will block the gate again the moment the auth layer is solved. But merging it will not turn review green by itself.

[kjgbot]

Blocked on two secrets — everything else on this gate is now solved

The hang is gone. Run 34016058718 (branch-scoped) failed in 13 seconds at the preflight. The two runs before it burned 11m12s and 12m18s on a device login. review is still RED, but it is now red fast and for a stated reason instead of timing out.

Root cause, proven from source and reproduced

agent-relay cloud run authenticates as a Cloud user session and nothing else. ensureCloudSession() resolves:

1. an env session requiring all four of CLOUD_API_URL, CLOUD_API_ACCESS_TOKEN, CLOUD_API_REFRESH_TOKEN, CLOUD_API_ACCESS_TOKEN_EXPIRES_AT — returns null silently if any is missing;
2. ~/.agentworkforce/relay/cloud-auth.json (a real login on disk);
3. interactive device login — reached on any Linux runner, because it is headless.

RELAY_WORKSPACE_KEY / RELAY_API_KEY / AGENT_RELAY_WORKSPACE_KEY are read by exactly one module, which selects a messaging workspace. The cloud auth path never reads them — which is why the earlier attempt to add that variable changed nothing. Confirmed server-side too: /api/v1/workflows/prepare (required by --sync-code) admits only a browser session or a cli:auth token, so an rk_live_* key is not a credential to that API.

What Khaliq needs to add — AgentWorkforce/flows -> Secrets -> Actions

secret	where it comes from
CLOUD_API_ACCESS_TOKEN	agent-relay cloud session --json --reveal-token, field accessToken
CLOUD_API_REFRESH_TOKEN	~/.agentworkforce/relay/cloud-auth.json, field refreshToken

Both from the same login, and it should be a login dedicated to CI — exporting a laptop session gives CI a credential either machine can invalidate.

CLOUD_API_URL and CLOUD_API_ACCESS_TOKEN_EXPIRES_AT are non-secret and default in the workflow.

Know what you are signing up for

This is a stopgap. A CLI login mints a 24h access token over a 90d refresh token, and refreshApiTokenSession() overwrites refreshTokenHash on every refresh — so the secret's copy is invalidated the first time it is used. Expect near-daily re-minting until the durable fix lands.

Durable fix filed as AgentWorkforce/cloud#3367: a long-lived non-refreshing CI token carrying cli:auth, minted like the existing 365-day deployment-api-tokens (which today carry only deployments:ci:* and cannot launch a workflow). It also asks that cloud run fail fast when non-interactive instead of opening a device flow.

Note for the other open PRs

#189, #193, #194, #196 keep the old 10-minute device-login behaviour until this lands on main — a same-repo pull_request takes the gate definition from the merge commit. Their red review checks say nothing about their contents.

No merge performed.