GitHub Archived Pull Requests: A Security Evidence Checklist

GitHub repository administrators can now archive pull requests instead of deleting their history or leaving abusive and spammy contributions in public view. GitHub documents that archiving closes and locks the pull request, hides it from non-admin visitors, and returns HTTP 404 to those visitors. Administrators can archive individually or in bulk, find archived items with is:archived, and later unarchive them; an unarchived pull request remains closed and locked.

That is useful moderation machinery, but it changes who can inspect review evidence. The feature should not become a shortcut for making unresolved security work disappear. The workflow below is inferred defensive guidance, not a GitHub requirement. CodeRiskTools did not test GitHub’s production authorization model, bulk-operation limits, or retention guarantees. Validate behavior in a non-critical repository and against your own plan, policies, audit exports, and incident procedures.

What archiving changes—and what it does not

Archiving changes visibility and interaction state. According to GitHub’s July 16, 2026 changelog, the pull request is closed and locked, remains visible to repository administrators, and can be restored to admin-visible history through unarchive. This differs from merging: archiving does not make the proposed commit part of the base branch. It also differs from deleting evidence outside GitHub; a ticket, exported audit record, CI log, or secret-rotation record follows its own retention controls.

Classify the pull request before hiding it

Use a reason code rather than an unstructured “clean up” label. A spam advertisement, harassment report, accidental secret disclosure, malware submission, duplicate bot pull request, abandoned experiment, and legitimate-but-rejected security fix have different response paths. The archive action may be appropriate for several of them, but the preconditions are not interchangeable.

• Spam or abuse: preserve the minimum moderation record required by policy, avoid repeating harmful text, then restrict public exposure.
• Exposed credential: rotate or revoke first. Hiding the pull request does not invalidate the credential or erase clones, notifications, logs, or forks.
• Malicious code: preserve a safe identifier and analysis outcome without copying a live payload into broad-access tickets.
• Security fix: record why it was rejected or superseded and link the accepted remediation, if one exists.
• Automation noise: identify the bot, rule, and deduplication failure before bulk archiving; otherwise the queue will refill.

A seven-step pre-archive workflow

1. Confirm authority and scope. Verify the repository, pull-request number, actor permission, and whether the action is individual or bulk. A list preview should be reviewed before a bulk operation.
2. Freeze an evidence pointer. Record immutable identifiers: repository, pull-request number, head and base commit SHAs, author, creation time, current state, and relevant ticket ID. Do not copy secrets or unnecessary personal data.
3. Resolve active risk. Revoke exposed credentials, contain malicious automation, or open a remediation issue. Visibility control is not incident closure.
4. Reconcile review state. Capture whether code review, status checks, security scanning, and policy checks ran against the final head SHA. “Checks passed” without a commit identity is weak evidence.
5. Apply a reason code. Use a bounded taxonomy such as spam, abuse, sensitive exposure, malicious submission, duplicate automation, or policy retention. Keep free text minimal.
6. Archive and read back. Confirm the pull request is closed and locked, verify expected non-admin visibility from a separate unauthenticated context, and confirm an authorized admin can still locate it with the documented archive filter.
7. Reconcile downstream systems. Ensure the moderation ticket, SIEM event, audit export, webhook consumer, and retention schedule agree on the final state. Record whether unarchive is allowed and who approves it.

Preserve security evidence without preserving secrets

A defensible record proves what was reviewed and why the visibility decision was made. It does not need raw credentials, exploit payloads, private customer data, or complete hostile comments. Prefer identifiers, hashes, redacted excerpts, scanner rule IDs, timestamps, and links restricted to the appropriate response group. If a pull request exposed a token, record the provider, rotation ticket, revocation time, and affected system—not the token value.

GitHub’s pull-request REST documentation is useful for retrieving structured pull-request data, while the organization audit-log documentation explains that audit entries include the actor, action, repository, and time for supported events. Do not assume every plan or action emits the exact event your policy needs: run a synthetic archive/unarchive rehearsal, inspect the resulting records, and document any gap before relying on the audit log as the sole evidence store.

Do not weaken merge controls while cleaning the queue

Archived noise and protected production branches solve different problems. GitHub documents that protected branches can require reviews, status checks, and other push conditions. Keep those controls independent from moderation. A cleaner pull-request list is not evidence that remaining changes are reviewed, and archiving a failed or suspicious proposal must not turn into a bypass for a replacement commit.

For AI-generated or bot-generated pull requests, bind each review result to the exact diff and head SHA. If automation opens a corrected replacement, run the checks again. Reusing an approval from the archived proposal can miss newly added files, changed dependencies, workflow permissions, or secret-bearing configuration.

Post-archive verification checklist

• The intended repository and pull-request number—not a similarly named item—were archived.
• The final head and base SHAs match the pre-action evidence record.
• The pull request is closed and locked after the operation.
• A non-admin or signed-out request observes the documented hidden behavior.
• An authorized administrator can find the item with is:archived.
• Any exposed credential is revoked or rotated independently of the archive action.
• The ticket contains a reason code, owner, timestamp, and reversible next step.
• Bulk counts reconcile: selected, archived, failed, skipped, and already archived.
• No secret, reusable authorization header, or unnecessary personal data entered the evidence package.
• Branch protection and required-check settings remain unchanged.

FAQ

Does an archived pull request disappear permanently?

GitHub says no: repository administrators can still see archived pull requests, and unarchiving makes them visible again while they remain closed and locked. Non-admin visitors to the archived URL receive a 404 response.

Should I archive a pull request that leaked a secret?

Archiving can reduce public visibility, but first rotate or revoke the credential and investigate exposure. The action does not invalidate a credential or remove copies from notifications, logs, forks, or local clones.

Can I bulk archive bot-generated pull requests?

GitHub documents bulk archiving. Use a previewable selection, stable reason codes, bounded batch size, and selected/pass/fail/skip reconciliation. Fix the automation source before treating bulk cleanup as complete.

Is an archived pull request proof that the repository is secure?

No. Archiving is a moderation and visibility control. It does not replace code review, protected branches, status checks, secret scanning, dependency review, or incident response.

Official sources and next step

• GitHub Changelog: repository admins can archive pull requests — vendor documentation for visibility, closed/locked state, bulk operations, unarchive, and is:archived.
• GitHub Docs: REST API endpoints for pull requests — current structured pull-request operations and fields.
• GitHub Docs: reviewing the organization audit log — documented audit-log scope, fields, and search workflow.
• GitHub Docs: about protected branches — current review, status-check, push, and deletion controls.

Continue with the CodeRiskTools guides for a safe merge workflow, pull-request security finding triage, and repository security review. The single comparison hub distinguishes workflow scope without presenting moderation features as security guarantees.