@findpainte-hub
This is a good question to ask before touching the setting, and it's worth saying up front: some of what you're asking (points 2, 4, 6, 7) genuinely isn't specified in the public docs. I'll go through what's documented vs. what isn't, rather than guessing at the undocumented parts.

What the docs actually say

The REST API endpoints for GitHub Actions permissions page defines the schema for GET/PUT /repos/{owner}/{repo}/actions/permissions like this:

• GET returns enabled, allowed_actions, selected_actions_url, and sha_pinning_required — but the docs' own example response is for the enabled: true case, where allowed_actions is present. There's no documented example or note for what the payload looks like when enabled: false, which is exactly the gap you've run into.
• For PUT, enabled is the only required body field. allowed_actions (all / local_only / selected) and sha_pinning_required (boolean) are both optional.
• The docs don't state what happens to allowed_actions or sha_pinning_required when they're omitted from a PUT — no "preserved," "reset to default," or "unspecified" language appears anywhere on that page.

So to your questions directly:

1. Is the GET response canonical when enabled: false? Not confirmed either way by docs — they don't describe reduced/partial responses tied to the enabled state at all.
2. Does absent allowed_actions mean unset, default, or hidden-while-disabled? Undocumented. All three of your hypotheses are consistent with what's written; the docs simply don't say.
3. Is there a read-only surface that exposes the stored value while disabled? None documented. The only other Actions-permissions read endpoint for repos is GET /repos/{owner}/{repo}/actions/permissions/selected-actions, but that's specifically for retrieving the selected-actions patterns list (used when allowed_actions=selected), not a general dump of stored-but-inactive policy. I couldn't find anything, REST or GraphQL, described as returning stored/inactive config independent of enabled state.
4. What happens to omitted fields on PUT? Undocumented — this is the same gap as Feature Request: Select a column when adding an issue to a project #2, just from the write side.
5. Can all three fields be supplied on both enable and disable calls? Yes, this one is answered — enabled is required either way, and allowed_actions/sha_pinning_required are listed as valid optional body parameters with no stated restriction tying them to a particular value of enabled. Nothing in the schema says they're rejected or ignored when enabled: false.
6. Does re-supplying all three guarantee the same stored policy? Not documented as a guarantee. It's the behavior you'd expect from a typical REST resource, but the docs don't explicitly promise idempotency here.
7. What request sequence restores state? No documented sequence exists for this specific scenario, since the underlying omitted-field behavior isn't documented in the first place.
8. Is this stable for 2026-03-10? Yes — this schema (enabled required, allowed_actions/sha_pinning_required optional, no field-omission semantics documented) is what's currently published for the latest API version, and it matches the equivalent org-level and GHES-version pages, so it's not a version-specific quirk or a recent change.

Practical suggestion

Since the omitted-field behavior isn't documented, the safe move — when you do authorize a change — is to always send all three fields explicitly on every PUT, rather than relying on omission to mean "leave as-is." That sidesteps points 2/4/6/7 entirely instead of depending on unspecified behavior. If you want to actually verify the mechanics (not just the risk-avoidance strategy), the only reliable way is empirical: run the sequence on a disposable throwaway repo first — PUT to disable, GET to confirm the disabled payload shape, PUT with all three fields to re-enable, GET again to compare — since that'll show you the real behavior on current infrastructure regardless of what the docs do or don't say.

For an authoritative answer to the undocumented parts specifically, GitHub Support(https://support.github.com/) or filing feedback via the "Ask a question" / "Make a suggestion" links at the bottom of that docs page are the two channels that reach the REST docs and Actions product teams respectively — this repo/community forum won't get you an official answer to the undocumented-behavior questions, only the documented ones.

Based on the current GitHub REST API documentation, I don't think the behavior you're asking about is fully specified.

For GET /repos/{owner}/{repo}/actions/permissions, GitHub documents enabled, allowed_actions, and sha_pinning_required as the repository Actions permission fields. The documented example response includes all three when they have values. The API documentation does not, however, explain what the absence of allowed_actions means when enabled is false.

More importantly, for PUT /repos/{owner}/{repo}/actions/permissions, GitHub documents enabled as required and allowed_actions and sha_pinning_required as optional. It does not state that omitting either optional field preserves its previous value, resets it, or removes a repository-specific setting. Therefore, I would not assume any of those behaviors unless GitHub confirms them.

The safest conclusion from the published documentation is:

• enabled must always be supplied to the PUT endpoint.
• allowed_actions, when supplied, must be one of all, local_only, or selected.
• sha_pinning_required, when supplied, is a boolean.
• The documentation does not define the persistence semantics of omitted optional fields.
• An absent allowed_actions in a GET response should therefore not be interpreted as proof that no value exists internally.
• I could not find a documented read-only endpoint that exposes a separate "stored" value for allowed_actions when Actions are disabled.

The documentation does confirm that the fields can be supplied together. For example, GitHub's own request example supplies:

{
  "enabled": true,
  "allowed_actions": "selected",
  "sha_pinning_required": true
}

and the endpoint returns 204 No Content on success.

However, this still doesn't establish that explicitly sending previously observed values is a guaranteed way to restore an identical internal repository policy. The API exposes the supported policy state, but the documentation does not promise that a GET → modify → PUT cycle is lossless when the GET response omitted a field.

Because of that, I would not recommend temporarily enabling Actions simply to discover the missing allowed_actions value if preserving the exact existing configuration is a requirement. There isn't enough documented information to guarantee that this operation can be performed and then reversed without changing some previously unspecified state.

For your specific case, where the initial response is:

{
  "enabled": false,
  "sha_pinning_required": false
}

with no allowed_actions, the only completely safe statement supported by the public documentation is that Actions are disabled and SHA pinning is not required. The documentation does not provide enough information to determine the repository's underlying allowed_actions value.

I would therefore ask GitHub staff to clarify whether the missing field is intentional API behavior when Actions are disabled and, specifically, whether omitted optional fields in the PUT request are preserved or otherwise modified.

This is particularly worth clarifying because the documentation for API version 2026-03-10 still does not appear to specify those semantics.

@nirav-gajera and @meshal10613, thank you both for taking the time to provide such careful and safety-conscious analyses.

Your replies confirm the central issue we needed to isolate: the public REST API contract does not define what an absent allowed_actions property means while enabled=false, nor does it guarantee the persistence semantics of omitted optional fields or a lossless rollback sequence.

We will therefore keep the target repository unchanged and will not temporarily enable GitHub Actions merely to discover the missing value.

Testing the behavior on an isolated temporary repository could provide useful empirical evidence about the current implementation, but it would not reveal the target repository’s latent baseline or provide a contractual guarantee that its original state could be restored exactly. Likewise, explicitly sending all three fields would only be safe if their initial values were already known or if a deliberate policy normalization had been separately reviewed and authorized.

We will keep this discussion open while seeking clarification from GitHub Staff, the GitHub Actions product team, the REST API documentation team, or authoritative official documentation.

If either of you encounters an official source defining:

1. the meaning of an absent allowed_actions field when enabled=false;
2. the behavior of omitted optional fields during PUT requests; and
3. the guarantees associated with restoring all previously observed policy values,

we would be very grateful if you could share it here.

Thank you again for helping us avoid an unsafe assumption.

I think the important point here is not to infer behavior that the API documentation doesn't actually promise.

If allowed_actions is missing from the GET response while Actions are disabled, I wouldn't assume that means “no value is stored” or that GitHub will preserve it if the field is omitted from a subsequent PUT. The documentation doesn't appear to make either guarantee.

Because this is a private repository and the goal is to preserve its existing configuration exactly, I agree with the decision not to temporarily enable Actions just to find out what happens. Testing on another repository could tell you how the API currently behaves, but it wouldn't tell you what the original hidden state of this particular repository was.

So I'd leave the repository untouched until GitHub clarifies the semantics. In this case, “we don't know” is a much safer answer than experimenting with a production repository and hoping the omitted fields are preserved.

@Mothukuri-venu, thank you for this careful and safety-focused confirmation.

Your distinction between observing current behavior on another repository and recovering the unknown latent baseline of this specific repository is particularly important. An empirical test could characterize current API behavior, but it could not prove that the target repository would be restored to its exact original state.

We will therefore keep the repository unchanged and continue waiting for authoritative clarification from GitHub Staff, the GitHub Actions product team, the REST API documentation team, or official documentation.

If you encounter an official source defining the omitted-field semantics or guaranteeing exact policy restoration, we would be grateful if you could share it here.

Thank you again for helping us preserve a fail-closed approach.