fix(github): make branch protection usable and wire workflow_id to its endpoint

[waleedlatif1]

Summary

Two verified GitHub defects: an operation that could never run, and a UI field wired to nothing.

github_update_branch_protection was unusable

PUT /repos/{owner}/{repo}/branches/{branch}/protection documents four body fields as required but nullable — required_status_checks, enforce_admins, required_pull_request_reviews, restrictions, each "Set to null to disable."

GitHub's "required" means present in the body, satisfiable by null. Sim's required: true means the user must supply a non-empty value — validateRequiredParametersAfterMerge rejects null, undefined and '' outright, so Sim could not express GitHub's disable case at all. Combined with restrictions having no subBlock anywhere in the block, every call threw Restrictions is required for GitHub Update Branch Protection before reaching the network.

• All four params → required: false
• request.body now emits an explicit null for each unset field instead of dropping the key, preserving GitHub's "present but null = disable" contract
• The body also normalizes the editor's JSON strings to objects and the dropdown's 'true'/'false' to booleans, fixing the type mismatches without touching tools.config.tool
• New restrictions subBlock, so the operation finally has full param coverage

workflow_id rendered but did nothing

The block showed a workflow_id field for github_list_workflow_runs, but the tool declared no such param and always hit the repo-wide /actions/runs. GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs exists, takes the identical query set, and returns the identical response schema — so this wires the field rather than deleting a working affordance. The segment is encodeURIComponent-escaped.

Design notes

Normalization lives in the tool's request.body, not in GITHUB_PARAM_ALIASES. Nothing here needs renaming, and the tool body covers the agent tool-calling path identically while carrying zero cross-operation clobber risk — the alias mapper is scoped by operation precisely because advanced fields serialize without their condition being evaluated.

The three pre-existing subBlocks stay mode: 'advanced'. With required: false that is now correct — they are genuinely optional — and flipping them would have changed visibility.

updateBranchProtectionV2Tool shares params and request by reference and inherits both fixes; a test asserts it.

Backwards compatibility

• subBlock ids: nothing renamed or removed; one added (restrictions). Subblock-ID stability check passes.
• required: only ever loosened (true → false), never tightened — no saved workflow can newly fail validation.
• visibility and mode: unchanged on every existing param.

The only behavior change is that an operation which always threw now runs, and a field that was discarded now takes effect.

Testing

apps/sim/tools/github/branch_protection_and_workflow_runs.test.ts — 41 tests; 151 pass across blocks/blocks/github and tools/github.

Verified red-first per guard, reverting each individually:

Guard	Red
required: false on the four params	5
explicit-null body emission	5
JSON-string parsing	2
boolean coercion	1
restrictions subBlock	1
json input types	1
workflow_id param	2
URL endpoint branch	4
encodeURIComponent	1
alias operation scoping	2
alias presence guard	6
parse-error message hardening	3

Two of those tests initially passed with their guard deleted and were rewritten. The presence-guard test used toEqual, which treats an undefined-valued key as absent — so {title: 'v1.0', description: undefined} compared equal to {title: 'v1.0'}. It now asserts on Object.keys, which is the distinction that actually matters when the provider spreads the transform over a model's tool-call arguments. The scoping test used real param names instead of alias source names and was rewritten to use milestone_title / gist_public / fork_name.

Includes coverage that a stale advanced value from another operation cannot leak into anything wired here.

bun run lint, type-check, check:audits (39 audits), tool-metadata:check, docs:check, integration-catalog:check, deployment-config:check and check-block-registry.ts origin/staging all pass. Regenerated artifacts committed.

Deferred: github_check_star

Confirmed dead and deliberately left alone. GitHub answers 204 for starred and 404 for not-starred; the shared executor throws on !response.ok before transformResponse runs, so starred: false is unreachable and the ordinary negative answer surfaces as a failure.

Three options exist — convert to an internal operation (isolated, but leaves the shared retry/DNS-pinning/size-limit machinery for one trivial GET), add an opt-in like expectedErrorStatuses on ToolConfig.request (generalizes, but sits on the hot path for every tool), or have callers read the status the thrown error already carries.

Worth noting for that decision: 13 GitHub tools use the status === 204 pattern, but 12 are mutations where any non-204 genuinely is an error — their false branch is harmless dead code, not a defect. check_star is the only GitHub tool where the non-2xx status carries meaning; the comparable live cases elsewhere are elasticsearch/get_document.ts and delete_document.ts. That makes it a three-tool problem rather than a ten-tool one, which argues against paying for the shared-executor change.

Type of Change

• Bug fix

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 31, 2026 9:42pm

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic review

[cubic-dev-ai]

@cubic review

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

All reported issues were addressed across 8 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[greptile-apps]

Greptile Summary

The PR makes GitHub branch-protection updates callable with nullable settings and connects workflow-run filtering to GitHub’s per-workflow endpoint.

• Adds explicit nullable body normalization and complete branch-protection block inputs.
• Adds optional workflow_id routing while preserving repository-wide listing when omitted.
• Updates generated metadata, integration documentation, deployment configuration, and regression coverage.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the prior invalid-string coercion issue is resolved because only normalized true, false, and nullable forms are accepted, while ambiguous values are rejected.

Important Files Changed

Filename	Overview
apps/sim/tools/github/update_branch_protection.ts	Normalizes nullable branch-protection objects and booleans; the previously reported truthiness bug is fixed by accepting only unambiguous values.
apps/sim/tools/github/list_workflow_runs.ts	Selects the encoded per-workflow runs endpoint when a workflow identifier is supplied.
apps/sim/blocks/blocks/github.ts	Adds the missing restrictions field and aligns branch-protection JSON input metadata.
apps/sim/tools/github/types.ts	Updates parameter types for optional nullable protection fields and workflow identifiers.
apps/sim/tools/github/branch_protection_and_workflow_runs.test.ts	Covers nullable request construction, strict boolean normalization, endpoint selection, encoding, block wiring, and stale-value containment.

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/sta..." | Re-trigger Greptile}

[cubic-dev-ai]

1 issue found across 8 files

Confidence score: 4/5

• In apps/sim/tools/github/branch_protection_and_workflow_runs.test.ts, the two “stale advanced value” tests expect the alias mapper to return {} for github_update_branch_protection and github_create_issue, while the mapper only emits configured GITHUB_PARAM_ALIASES entries. This may leave the intended stale-value behavior unclear or make the tests brittle—align the assertions with the current alias configuration and tool behavior.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/sim/tools/github/branch_protection_and_workflow_runs.test.ts">

<violation number="1" location="apps/sim/tools/github/branch_protection_and_workflow_runs.test.ts:229">
P2: These two 'stale advanced value' tests assert the alias-mapper output is {} for github_update_branch_protection and github_create_issue. That mapper only emits GITHUB_PARAM_ALIASES entries, and none of restrictions/workflow_id/enforce_admins/required_status_checks are aliases, so the assertion is always true and the tests cannot fail. They do not exercise the leak path (`shouldSerializeSubBlock`/generic-handler's `{...inputs, ...params(inputs)}` merge) the comments describe, so they provide no regression protection against stale advanced values leaking between operations. Assert on the full merged inputs that generic-handler feeds to the tool (or a test that toggles the operation after filling an advanced field) instead of the alias mapper.</violation>
</file>

<sub>Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.

Fix all with cubic | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic review

[cubic-dev-ai]

@cubic review

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 8 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}