Cloud Automation: dashboard secret injects on scheduled runs but not on GitHub label triggers

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

On the same Cursor account and repository, a scheduled/manual Cloud Automation receives my user-scoped dashboard secret (fine-grained GitHub PAT), but a GitHub label-triggered Cloud Automation on the same repo does not.

Label-triggered runs: operator PAT env var missing, temp auth env file from start hook absent, gh auth status shows Cursor integration token (ghs_…), gh api user returns 403 “Resource not accessible by integration”.

Scheduled/manual runs: start log shows PAT applied / auth configured successfully.

git push still works in label-triggered runs (integration token). gh pr comment and gh pr edit fail (need operator PAT). Solo account (no team plan). Secret name and dashboard config verified working via the scheduled automation path.

Regression I am experiencing:

  • Label-triggered automation completed gh pr write operations (comments, labels) until approximately 4-5 days ago
  • Unchanged since then: dashboard secret name/config, GitHub label trigger filter, repo, account.
  • Changed since then: automation prompts (auth gates, runbook instructions) and start-hook auth wiring (wait/retry, source-safe gh setup). I have not isolated whether prompt/hook changes matter — current shell diagnostics show the operator PAT env var is missing before any agent-authored gh command runs.
  • Scheduled/manual automation path still receives the secret today — points to label/webhook session startup or secret injection differing by trigger type, not PAT expiry or a wrong secret name.

Steps to Reproduce

  1. Add a fine-grained GitHub PAT to Cloud Agents → Secrets (user scope) under a dedicated env var name (not GH_TOKEN). Do not use GH_TOKEN alone — Cursor may inject ghs_… as GH_TOKEN.

  2. Commit .cursor/environment.json on a GitHub repo with install + start hooks; start hook waits briefly for secret injection then configures gh auth.

  3. Create Automation A: same repo, trigger = schedule or manual. Run it. In start logs, confirm PAT applied / auth configured successfully.

  4. Create Automation B: same repo, same environment.json, trigger = GitHub pull request label changed (filter to one custom label).

  5. Add that label to an open PR. Automation B starts.

  6. In the Automation B agent shell (do not print secret values):
    test -n “$YOUR_PAT_ENV_VAR” && echo set || echo missing
    gh auth status
    gh api user -q .login

  7. Compare with Automation A agent shell using the same checks.

Expected Behavior

Label-triggered Background Agent / Cloud Automation sessions receive the same user-scoped dashboard Secrets as scheduled or manual runs on the same account and repo. After the documented auth setup in the agent shell, gh api user -q .login returns my GitHub user (not cursor / not 403 integration).

Operating System

Windows 10/11

Version Information

Version: 3.7.19 (user setup)
VS Code Extension API: 1.105.1
Commit: 80c653c2c3528e65016a0d304b54486084b470b0
Date: 2026-06-07T01:42:56.126Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

N/A — platform/infrastructure issue (secret injection into Cloud Automation VM), not a single chat model response. Automations use Cloud Agent default / Max Mode models.

For AI issues: add Request ID with privacy disabled

Background Agent run IDs

Automation A (scheduled/manual — secret injects): bc-667e981e-c1b2-4474-87e0-aeab4c8d3591 [privacy disabled]

Automation B (label trigger — secret missing): bc-304072b7-e9e1-424f-92e6-d2d93e124afc [privacy disabled]

Automation B (label trigger - secret injects [regressed]): bc-14ad5c82-14f1-4001-8aa1-23882d31dad2 [privacy enabled]

Additional Information

Diagnostic table (label-triggered run):

Check Result
Operator PAT env var missing
GH_TOKEN unset (no non-ghs_ fallback)
Temp auth env file from start hook absent
gh auth status Cursor integration token (ghs_…)
gh api user 403 Resource not accessible by integration

Scheduled/manual start log (same account, same secret):
[PAT applied / auth configured successfully]
Running desktop init script

Already tried:

  • Re-saving secret in dashboard Secrets
  • Sourcing auth in agent shell per Cloud Agent docs
  • Start-hook wait/retry for secret injection (up to 30s)
  • Confirmed scheduled path receives secret — dashboard config appears correct

Impact: label-triggered automation cannot complete gh pr write operations; workaround is manual gh from local machine.

Questions:

  1. Is secret injection intentionally different for GitHub webhook/label automations vs scheduled/manual?
  2. Supported way to ensure user Secrets inject into label-triggered sessions?
  3. Recommended workaround besides manual handoff?

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi Shervin, thank you for the incredibly detailed report and diagnostics. You’ve read this correctly: your user dashboard secrets should inject the same way regardless of trigger type, so the label-triggered runs missing your PAT is a bug on our side, not intended behavior.

the ghs_… token in gh auth status (and git push still working) is expected. That’s the Cursor GitHub App installation token used for clone/push, and it’s separate from your user PAT. So nothing is wrong there. The only real issue is your user-scoped secret not being injected on the label-triggered path, which is why gh pr comment / gh pr edit come back 403.

We’re tracking this (it was fixed briefly but regressed, so we’ve reopened it). In the meantime, the most reliable unblock is exactly what you already found works: run the automation on the schedule/manual path, or launch into the same environment via the API, both of which inject your secret correctly. I’ll keep you posted as the fix lands.

Hi @kevinn,

Just wanted to report, that this issue is still open..