Workspace secret GH_PAT not exported as GH_TOKEN; molecule-git-token-helper.sh also doesn't fall back to it #1687

New Issue

2026-05-22T21:21:35Z

2026-05-22 21:21:35 +00:00

Summary

The Molecule platform stores a GH_PAT workspace secret with a working GitHub Personal Access Token, but neither (a) the gh CLI nor (b) the platform's molecule-git-token-helper.sh credential helper find it. Result: agents that need to clone or pull private GitHub repos in their cloud env get "all token sources exhausted" / "Authentication failed" even though the credential IS available — they just need to be told the right env-var name.

This is filed as a follow-up to #1684 (same investigation surfaced both).

Tenant + repro context

Tenant: reno-stars.moleculesai.app
Workspace (SEO Agent): 3fe84b89-eb65-42fc-ad1f-5c93582ca3e7
Target repo: Reno-Stars/reno-star-business-intelligent (private)
Discovered: 2026-05-22 ~20:46 UTC during direct A2A debugging with the agent

What the agent sees

Workspace secrets API (GET /workspaces/{id}/secrets) returns:

[
  { "key": "GH_PAT",  "has_value": true, "scope": "workspace", "created_at": "2026-05-20T22:05:19Z" },
  { "key": "GH_USER", "has_value": true, "scope": "workspace" },
  { "key": "GH_REPO", "has_value": true, "scope": "workspace" },
  { "key": "GIT_EMAIL", ... },
  { "key": "GIT_NAME",  ... }
]

Agent env (from the agent's own printenv inside its cloud runtime):

GH_PAT:        SET   (value_len=40, classic PAT format)
GH_TOKEN:      EMPTY
GITHUB_TOKEN:  EMPTY
GITHUB_PAT:    EMPTY
GH_USER:       SET   (value_len=11)
GH_REPO:       SET   (value_len=28)

So the secret IS exported into the runtime — under the literal name GH_PAT. But:

1. `gh` CLI doesn't recognize `GH_PAT`

gh repo clone Reno-Stars/reno-star-business-intelligent returns:

To get started with GitHub CLI, please run: gh auth login
Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token.
exit=4

The gh CLI specifically looks at GH_TOKEN (or GITHUB_TOKEN). It does not fall back to GH_PAT.

2. `molecule-git-token-helper.sh` doesn't recognize `GH_PAT` either

git clone https://github.com/Reno-Stars/reno-star-business-intelligent.git returns:

[molecule-git-token-helper] all token sources exhausted
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/Reno-Stars/reno-star-business-intelligent.git/'
exit=128

So the bundled credential helper that's wired into the agent's .gitconfig doesn't check GH_PAT even though it's the obvious place to find one.

3. Workaround that works

The agent and I confirmed this works:

GH_TOKEN=$GH_PAT gh repo clone Reno-Stars/reno-star-business-intelligent ... --depth 1 --quiet
# exit=0 ✓

i.e. inline-prefixing GH_TOKEN=$GH_PAT makes both gh CLI and the credential helper see the token. So the value is correct; only the env-var name plumbing is broken.

We've patched our 11 cron schedules to do this prefix everywhere they invoke git/gh. It works but is ugly — every gh/git command needs the inline prefix, and any third-party tool that just calls git pull without the prefix will still fail.

Proposed fix (any one of these would resolve)

A. Workspace secret-injection layer also exports GH_PAT as GH_TOKEN. The simplest fix. When the platform reads the GH_PAT secret to inject it into the runtime, also inject an identical GH_TOKEN env var. (Or alias.) This makes gh CLI work out of the box and matches the convention every other GitHub-aware tool expects.

B. molecule-git-token-helper.sh looks at GH_PAT as a fallback. Order it tries: GH_TOKEN → GITHUB_TOKEN → GH_PAT → GITHUB_PAT. This fixes git operations even without the prefix, and would match how tools like Dependabot, Renovate, etc. behave.

C. Rename the canonical secret to GH_TOKEN. Most invasive — workspaces would need to update which secret name they reference. But would be the cleanest long-term.

Strong preference for A or A+B. Both are mechanical, don't affect any existing workspace's setup, and immediately fix the "obvious" path. Renaming (C) breaks existing scripts.

Why this matters for the SSOT pattern

Our workspace operates on the "SSOT in git" pattern — every cron tick git pulls its policy + skill content from a private GitHub repo. With the current setup, that pull silently fails (the helper says "exhausted" and gh says "no auth"), and the agent falls back to whatever it remembers from prior ticks. That defeats the entire pattern: policy changes pushed to git never propagate to the agent.

We've worked around it with the GH_TOKEN=$GH_PAT inline prefix and it's stable now, but it's a footgun for the next person doing a Molecule + private-repo setup.

Reproduction

On any workspace with a private repo dependency, set the secret as GH_PAT (the natural-looking name).
Spin up a runtime, exec into it, run gh repo clone <private-repo> or git clone <private-repo>.
Observe both fail with auth errors even though the secret is set.
Run printenv | grep GH — GH_PAT is there, GH_TOKEN is not.

— Hongming Wang (airenostars@gmail.com)
— Tenant: reno-stars.moleculesai.app
— Workspace owner: d76977b1-f17e-4a4c-9f74-bf6315238620

## Summary The Molecule platform stores a `GH_PAT` workspace secret with a working GitHub Personal Access Token, but neither (a) the gh CLI nor (b) the platform's `molecule-git-token-helper.sh` credential helper find it. Result: agents that need to clone or pull private GitHub repos in their cloud env get "all token sources exhausted" / "Authentication failed" even though the credential IS available — they just need to be told the right env-var name. This is filed as a follow-up to #1684 (same investigation surfaced both). ## Tenant + repro context - **Tenant:** `reno-stars.moleculesai.app` - **Workspace (SEO Agent):** `3fe84b89-eb65-42fc-ad1f-5c93582ca3e7` - **Target repo:** `Reno-Stars/reno-star-business-intelligent` (private) - **Discovered:** 2026-05-22 ~20:46 UTC during direct A2A debugging with the agent ## What the agent sees Workspace secrets API (`GET /workspaces/{id}/secrets`) returns: ```json [ { "key": "GH_PAT", "has_value": true, "scope": "workspace", "created_at": "2026-05-20T22:05:19Z" }, { "key": "GH_USER", "has_value": true, "scope": "workspace" }, { "key": "GH_REPO", "has_value": true, "scope": "workspace" }, { "key": "GIT_EMAIL", ... }, { "key": "GIT_NAME", ... } ] ``` Agent env (from the agent's own `printenv` inside its cloud runtime): ``` GH_PAT: SET (value_len=40, classic PAT format) GH_TOKEN: EMPTY GITHUB_TOKEN: EMPTY GITHUB_PAT: EMPTY GH_USER: SET (value_len=11) GH_REPO: SET (value_len=28) ``` So the secret IS exported into the runtime — under the literal name `GH_PAT`. But: ### 1. `gh` CLI doesn't recognize `GH_PAT` `gh repo clone Reno-Stars/reno-star-business-intelligent` returns: ``` To get started with GitHub CLI, please run: gh auth login Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token. exit=4 ``` The gh CLI specifically looks at `GH_TOKEN` (or `GITHUB_TOKEN`). It does not fall back to `GH_PAT`. ### 2. `molecule-git-token-helper.sh` doesn't recognize `GH_PAT` either `git clone https://github.com/Reno-Stars/reno-star-business-intelligent.git` returns: ``` [molecule-git-token-helper] all token sources exhausted remote: Repository not found. fatal: Authentication failed for 'https://github.com/Reno-Stars/reno-star-business-intelligent.git/' exit=128 ``` So the bundled credential helper that's wired into the agent's `.gitconfig` doesn't check `GH_PAT` even though it's the obvious place to find one. ### 3. Workaround that works The agent and I confirmed this works: ```bash GH_TOKEN=$GH_PAT gh repo clone Reno-Stars/reno-star-business-intelligent ... --depth 1 --quiet # exit=0 ✓ ``` i.e. inline-prefixing `GH_TOKEN=$GH_PAT` makes both gh CLI and the credential helper see the token. So the value is correct; only the env-var name plumbing is broken. We've patched our 11 cron schedules to do this prefix everywhere they invoke git/gh. It works but is ugly — every gh/git command needs the inline prefix, and any third-party tool that just calls `git pull` without the prefix will still fail. ## Proposed fix (any one of these would resolve) **A. Workspace secret-injection layer also exports `GH_PAT` as `GH_TOKEN`.** The simplest fix. When the platform reads the `GH_PAT` secret to inject it into the runtime, also inject an identical `GH_TOKEN` env var. (Or alias.) This makes gh CLI work out of the box and matches the convention every other GitHub-aware tool expects. **B. `molecule-git-token-helper.sh` looks at `GH_PAT` as a fallback.** Order it tries: `GH_TOKEN` → `GITHUB_TOKEN` → `GH_PAT` → `GITHUB_PAT`. This fixes git operations even without the prefix, and would match how tools like Dependabot, Renovate, etc. behave. **C. Rename the canonical secret to `GH_TOKEN`.** Most invasive — workspaces would need to update which secret name they reference. But would be the cleanest long-term. **Strong preference for A or A+B.** Both are mechanical, don't affect any existing workspace's setup, and immediately fix the "obvious" path. Renaming (C) breaks existing scripts. ## Why this matters for the SSOT pattern Our workspace operates on the "SSOT in git" pattern — every cron tick `git pull`s its policy + skill content from a private GitHub repo. With the current setup, that pull silently fails (the helper says "exhausted" and gh says "no auth"), and the agent falls back to whatever it remembers from prior ticks. That defeats the entire pattern: policy changes pushed to git never propagate to the agent. We've worked around it with the `GH_TOKEN=$GH_PAT` inline prefix and it's stable now, but it's a footgun for the next person doing a Molecule + private-repo setup. ## Reproduction 1. On any workspace with a private repo dependency, set the secret as `GH_PAT` (the natural-looking name). 2. Spin up a runtime, exec into it, run `gh repo clone <private-repo>` or `git clone <private-repo>`. 3. Observe both fail with auth errors even though the secret is set. 4. Run `printenv | grep GH` — `GH_PAT` is there, `GH_TOKEN` is not. — Hongming Wang (airenostars@gmail.com) — Tenant: reno-stars.moleculesai.app — Workspace owner: `d76977b1-f17e-4a4c-9f74-bf6315238620`

RenoStarsAI-production-client referenced this issue

2026-05-22 21:25:09 +00:00

Workspace-attached repo is provisioned as a flat directory (no `.git/`) — `git pull` impossible #1688