github setup prompts for app PEM when apps already exist in the org

[guyoron1]

What happens

Running github setup against an org where GitHub Apps are already installed prompts for a .pem file path for each role:

App <slug> exists but its private key is missing.
Do you already have the .pem file? [Y/n]

What should happen

github setup uses OIDC mint mode (--mint-url). The mint holds all PEMs. When an app is already installed, it should be reused silently without prompting for a local key file.

Context

runGitHubSetupPerOrg calls runAppSetup with empty mintProject, so no gcf.Provisioner is created. The fallback secretExists callback checks GitHub repo secrets (FULLSEND_<ROLE>_APP_PRIVATE_KEY), which don't exist in OIDC-mint-mode installs (PEMs are in Secret Manager). The check returns false → handleExistingApp → recoverPEM → interactive prompt.

Relevant code

• internal/cli/github.go:502 — runAppSetup call with empty mintProject
• internal/cli/admin.go:1346–1357 — GitHub-secrets secretExists fallback
• internal/appsetup/appsetup.go:580–611 — handleExistingApp → recoverPEM

---

Mirrored from fullsend-ai#2163

[guyoron1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 2:27 PM UTC · Completed 2:29 PM UTC
Commit: bb5c185 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: High — blocks non-interactive re-runs of github setup in OIDC mint mode.

Problem: Running github setup --mint-url against an org with pre-existing GitHub Apps triggers an interactive PEM file prompt for each role, instead of silently reusing the apps.

Root cause hypothesis: runGitHubSetupPerOrg passes an empty mintProject to runAppSetup, preventing gcf.Provisioner creation. The secretExists fallback checks GitHub repo secrets (FULLSEND_<ROLE>_APP_PRIVATE_KEY), which don't exist in mint mode (PEMs live in Secret Manager). This false negative triggers handleExistingApp → recoverPEM → interactive prompt.

Recommended fix: Propagate mint configuration into runAppSetup so that secretExists checks Secret Manager when in mint mode, or skip PEM recovery entirely when the mint service manages keys.

Key files:

• internal/cli/github.go:502 — runAppSetup call with empty mintProject
• internal/cli/admin.go:1346–1357 — GitHub-secrets secretExists fallback
• internal/appsetup/appsetup.go:580–611 — handleExistingApp → recoverPEM

Proposed test case:

Scenario: mint mode with existing app skips PEM recovery
  Given a forge client that returns an existing GitHub App
  And mint mode is active (non-empty mint URL)
  When runAppSetup is called
  Then the app is reused without calling recoverPEM
  And no interactive prompt is triggered

Scenario: non-mint mode with missing secret still prompts
  Given a forge client that returns an existing GitHub App
  And mint mode is NOT active
  And the repo secret FULLSEND_<ROLE>_APP_PRIVATE_KEY does not exist
  When runAppSetup is called
  Then recoverPEM is invoked and the user is prompted for the .pem path

---

Labels: CLI setup bug affecting mint-mode PEM handling, confirmed defect with high priority due to blocking non-interactive workflows.

[guyoron1]

/fs-code

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 2:37 PM UTC · Completed 2:40 PM UTC
Commit: bb5c185 · View workflow run →

[guyoron1]

/fs-code

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 2:45 PM UTC · Completed 2:47 PM UTC
Commit: bb5c185 · View workflow run →