How can I detect pending workflow enablement on a fork when the permissions API returns enabled: true?

[muescha]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

API

Body

Hi,

I’m trying to check, using the GitHub CLI or API, whether workflows have been enabled on my forked repositories. I want to read their current status without changing any settings or triggering workflow runs.

For one of my public forks, the API response and the Actions page appear to disagree.

Repository: https://github.com/muescha/lsp4ij
Actions page: https://github.com/muescha/lsp4ij/actions

When I open the Actions page while signed in as the repository owner, GitHub displays:

Workflows aren't being run on this forked repository

The page also displays the button “I understand my workflows, go ahead and enable them.”

However, this read-only API request:

gh api \
  --method GET \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  repos/muescha/lsp4ij/actions/permissions

returns:

{
  "enabled": true,
  "allowed_actions": "all",
  "sha_pinning_required": false
}

According to the documentation for Get GitHub Actions permissions for a repository, this endpoint includes whether GitHub Actions is enabled.

The individual workflow states also do not seem to expose the restriction:

gh api --paginate \
  'repos/muescha/lsp4ij/actions/workflows?per_page=100' \
  --jq '.workflows[] | [.name, .state] | @tsv'

All eight workflows return active; none returns disabled_fork.

I found this comment in discussion #104281, which suggests enabling Actions on a fork by calling PUT /repos/{owner}/{repo}/actions/permissions with {"enabled": true}.

My question concerns the read-only counterpart: GET on that same endpoint already returns enabled: true, even though the Actions page still asks me to enable workflows on the fork.

I have deliberately not clicked the enablement button or tried the suggested PUT request, because I want to preserve the current state for investigation. The enablement prompt is visible in my authenticated owner view; I understand that other visitors may not see the same page.

My questions are:

1. Is there a supported, read-only REST API endpoint, GraphQL field, or GitHub CLI command that tells me whether a fork is still waiting for this initial workflow enablement?
2. What exactly does enabled: true mean when the Actions page still says that workflows are not being run?
3. Is this discrepancy expected behavior, or should it be reported as a bug?

I’m specifically looking for a way to read the current state. Enabling Actions would change the setting rather than let me detect whether the initial enablement is still pending.

Thanks!

[bytesbydev]

I think the key point here is that enabled: true might only reflect the repository’s Actions permissions, not whether workflows on a fork have been explicitly approved to run.

It would be helpful to know if GitHub exposes this initial enablement state through a separate read-only API or CLI command. Otherwise, it’s difficult to reliably check the status without changing anything.

Since the Actions page and API response appear to disagree, I think this is worth clarifying with GitHub. A documented way to check the pending state would be really useful for automation.

[Sagargupta16]

There is no documented read-only field for the fork banner. The two calls you ran measure different things.

GET /repos/{owner}/{repo}/actions/permissions is the repository policy. Its description: "Gets the GitHub Actions permissions policy for a repository, including whether GitHub Actions is enabled and the actions and reusable workflows allowed to run in the repository." enabled: true is the Settings > Actions > General toggle, which a fork inherits. It knows nothing about the "Workflows aren't being run on this forked repository" gate.

The only documented marker for that gate is the per-workflow state. REST workflow.state is active | deleted | disabled_fork | disabled_inactivity | disabled_manually, and GraphQL WorkflowState.DISABLED_FORK is "The workflow was disabled by default on a fork." When the gate shows up in the API at all, it shows up there, and gh workflow list --all prints it.

Your fork does not carry it, yet the gate is visible in the data:

• all 8 workflow objects were created at 2026-10-20T17:00:19Z, the exact timestamp of your push to refs/heads/main that day;
• ci.yml has on: push: branches: [main], so that push should have produced a run;
• GET /repos/muescha/lsp4ij/actions/runs returns total_count: 0.

One of my own forks looks the same (2 active workflows, 0 runs since the fork), so active on a gated fork is not unique to you. I could not find what decides between active and disabled_fork in the docs.

Read-only check that works today:

gh api repos/muescha/lsp4ij --jq '.fork'
gh api 'repos/muescha/lsp4ij/actions/workflows?per_page=100' --jq '[.workflows[].state] | unique'
gh api 'repos/muescha/lsp4ij/actions/runs?per_page=1' --jq '.total_count'

fork: true, workflows present, and total_count: 0 after a push that matches a trigger means the gate is still on. Any disabled_fork state is a definite yes.

On your third question: the API not reflecting the banner while state stays active is worth filing as a Bug in the Actions category, with the timestamps above.