Azure Static Web Apps deployment workflow never runs and GitHub reports "Actions has been disabled for this user"

Question

Question

Answer 1

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure Static Web Apps deployment workflow never runs and GitHub reports "Actions has been disabled for this user".

The deployment is failing before Azure Static Web Apps can build or deploy the app. The GitHub-side error: HTTP 422: Actions has been disabled for this user means that GitHub is blocking workflow execution for the user/account/repository context. - https://learn.microsoft.com/en-us/azure/static-web-apps/publish-devops, https://learn.microsoft.com/en-us/azure/static-web-apps/build-configuration.

The best method to resolve is to:

Stop changing Azure Static Web Apps build settings until GitHub Actions can create a run.
Verify GitHub Actions is enabled at repository and organization level.
If the account-level error remains, escalate to GitHub Support for account restriction review.
For immediate deployment, move the repository to an unrestricted GitHub account/org or use Azure DevOps.
Reset the Azure Static Web Apps deployment token and update the repository secret.
Use a clean Static Web Apps workflow with push, pull_request, and workflow_dispatch.

After moving the deployment to an unrestricted GitHub account or Azure DevOps and updating the Static Web Apps deployment token, the workflow should create a run. Only after a workflow run starts should you troubleshoot app_location, api_location, output_location, build commands, Oryx, or deployment-token errors.

Use the below resource links for more reading and implementation steps:

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Answer 2

Salamat Shah 740 MVP

Dear Hossain,

The most likely cause is that the GitHub account or organization has a restriction preventing custom GitHub Actions from running. Azure Static Web Apps relies on GitHub Actions, so deployments will never start until Actions can execute.

But try below:

Verify the account's current status with GitHub Support and confirm any previous restrictions have been fully removed.
Test with a different unrestricted GitHub user that has admin access to the repository.
Check the repository and organization Actions settings for any user-specific restrictions or pending workflow approvals.
Confirm the Azure Static Web Apps workflow contains valid on: push and/or workflow_dispatch triggers.
Once GitHub Actions can run normally, reconnect the Static Web App to recreate the webhook and deployment workflow.

Moazzem Hossain 80 Reputation points

2026-07-28T18:57:28.25+00:00
Thank you for the guidance provided earlier.

After further investigation, I believe the issue extends beyond Azure Static Web Apps configuration and is instead related to a GitHub account restriction affecting organization administration.

Additional Findings

I successfully authenticated to GitHub using the LTBD-Admin account.

Using GitHub CLI, I verified the invitation for the Talent-Bridge-BD organization:

Membership state: pending

Assigned role: admin

However, when attempting to accept the invitation, GitHub returns:

You cannot accept this invitation because your account has been flagged.
HTTP 422

I also verified the current repository permissions for LTBD-Admin:

Pull: True

Push: False

Admin: False

This indicates that the account can authenticate successfully but cannot activate organization membership or receive the assigned administrative permissions because the account remains flagged.

Intended Governance Model

My intended organization model is:

LTBD-Admin – Human administrator account responsible for:

Organization ownership

Administrative settings Security and governance Billing and account administration **MoazzemHossain-bot** – Service/automation account used for: GitHub Actions CI/CD Azure DevOps integrations Deployment automation

The goal is to separate human administration from automation in accordance with GitHub best practices.

Additional Verification

I also confirmed that historical repository commits were attributed to MoazzemHossain-bot because the repositories were previously configured to use that account's GitHub noreply email address. Future commits have now been reconfigured to use my human administrator identity.

Support History

This issue appears to be related to several previous GitHub Support cases concerning account restrictions, organization administration, ownership recovery, and governance. The relevant cases include:

#4607318 – Request review of account restriction affecting organization administration

#4594240 – Request for Account Reinstatement Review

#4173812 – Request for account reinstatement

#4102136 – Account flagged with administrative_block – LTBD-Admin

#3659439 – Reinstatement Request

#4273500 – Organization has no active human owner – ownership recovery and correction

The issue has been ongoing since 2025, and the current investigation indicates that the same underlying account restriction continues to prevent the intended governance model from being implemented.

Current Issue

The remaining blocker is that LTBD-Admin cannot accept the organization invitation because the account is flagged, preventing the intended ownership and governance model from being established.

As a result:

LTBD-Admin can authenticate successfully.

The Talent-Bridge-BD organization invitation remains pending.

The assigned administrator role cannot be activated.

GitHub returns HTTP 422 when the invitation is accepted because the account is flagged.

Administrative responsibilities cannot be transferred to the intended human administrator account.

I have attached screenshots showing the pending organization invitation and the HTTP 422 error.

I would appreciate your assistance in reviewing the related support history together with the current findings, confirming whether the existing account restriction is the remaining blocker, and advising how the LTBD-Admin account can complete the organization invitation and assume its intended administrative responsibilities.

Thank you for your continued assistance.
Moazzem Hossain 80 Reputation points

2026-08-06T21:23:34.1833333+00:00
Additional Investigation Update

I would like to provide an additional finding that may help narrow down the root cause.

GitHub Organization: Talent-Bridge-BD
Administrative Account: LTBD-Admin

The LTBD-Admin account was intended to serve as the primary organization owner/administrator account. However, GitHub API responses currently indicate the following organization membership state:

state: pending role: admin direct_membership: false

This raises an important question: if the organization membership is still reported as pending, is this expected behavior for an organization administrator account? How was the organization originally created, and how were administrative permissions assigned and maintained?

Current Observations

The GitHub organization exists and repositories are accessible.

LTBD-Admin appears to have an administrative role within the organization, but the membership is not shown as an active direct membership.

MoazzemHossain-bot can push code and interact with repositories.

GitHub-managed workflows, such as CodeQL, execute successfully.

User-created workflows remain at 0 runs.

Manual workflow execution using the automation account returns:

HTTP 422: Actions has been disabled for this user

Attempting administrative workflow operations using LTBD-Admin returns:

HTTP 403: Must have admin rights to Repository

despite the account appearing to have an administrative organization role.

Question

Could a pending organization membership state, a previously restricted GitHub account, or a GitHub Trust & Safety/account-level limitation result in this combination of behavior?

The observed symptoms are:

Repository workflows appear as Active.

GitHub-managed workflows (for example, CodeQL) execute successfully.

Custom workflows are never scheduled.

Manual workflow dispatch returns:

HTTP 422: Actions has been disabled for this user

Administrative API operations return:

HTTP 403: Must have admin rights to Repository

even though the account appears to have administrative privileges.

Additional Context

The Azure Static Web Apps resource appears to be correctly configured and contains valid deployable content:

index.html privacy.html terms.html

The deployment process has not reached Azure because GitHub Actions has never created a workflow run.

Based on the evidence collected so far, I would like to confirm whether the underlying issue is related to:

GitHub account status,

organization membership state,

repository permission configuration,

or a GitHub Actions restriction applied at the account or organization level.

Has anyone encountered a similar scenario where GitHub-managed workflows run successfully, but user-created workflows remain at 0 runs and manual workflow dispatch consistently returns HTTP 422?

Any guidance on the correct remediation path would be greatly appreciated.

Thank you.

Azure Static Web Apps deployment workflow never runs and GitHub reports "Actions has been disabled for this user"

2 answers

Additional Findings

Intended Governance Model

Additional Verification

Support History

Current Issue

Additional Investigation Update

Current Observations

Question

Additional Context

Your answer