[Brooooooklyn]

What

Adds a --workflow <path> flag to void github connect and void github update, letting the project owner configure which workflow file the platform authorizes to mint an OIDC deploy token. Defaults to the scaffolded .github/workflows/void-deploy.yml.

void github connect my-app --repo owner/app --executor github_actions --workflow .github/workflows/ci.yml
void github update  my-app --workflow .github/workflows/deploy.yml

Why

The authorized deploy workflow was previously hardcoded server-side. This lets owners point the OIDC trust at their own workflow file (it must live under .github/workflows/ and end in .yml/.yaml). The API is authoritative for validation and storage; the CLI just forwards the value.

Details

• github-args: parse --workflow for both connect and update (trimmed, value-required).
• github-cmd: thread workflowPath into connect; update treats it as flag-only (no interactive prompt) and no-ops when unchanged.
• client: send workflowPath in the POST/PATCH bodies; add workflow_path to the GithubConnection type.
• Fail closed: connect/update verify the server echoed the requested workflow_path and exit non-zero otherwise, so a CLI pointed at an older API (which silently drops the field) can't leave the user believing a custom workflow is authorized.
• help + docs/reference/cli.md: document the flag and its security semantics.

Testing

vp test run — github CLI unit tests (parser + connect/update threading + fail-closed verification) all pass; typecheck/fmt/lint clean.

Pairs with a platform-side PR that adds the server workflow_path column, owner-gated routes, and the OIDC pin.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes which workflow may mint deploy tokens (security-sensitive OIDC trust), though validation is server-side and the CLI fails closed when the platform does not apply the path.

Overview
Adds --workflow <path> to void github connect and void github update so project owners can configure which GitHub Actions workflow file the platform trusts for OIDC deploy-token minting (default .github/workflows/void-deploy.yml).

The CLI parses the flag, sends optional workflowPath on connect/update API calls, and extends GithubConnection with workflow_path. On update, workflow changes are flag-only (no TTY prompt), count toward the non-interactive “at least one flag” guard, and patch only when the value differs. Connect and update fail closed if the user passed --workflow but the response workflow_path does not match—avoiding silent success against an older API that ignores the field.

Help text and docs/reference/cli.md document the flag and OIDC trust semantics. Unit tests cover parsing, update threading, no-op behavior, and old-platform verification.

^{Reviewed by Cursor Bugbot for commit ef845e8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_b7cbf8a6-de57-416c-9af7-6f27c8642b76)