How to Give GitHub Access to Technical Support

Use this guide when the support team needs access to a GitHub repository to review code, diagnose a bug, prepare a fix, create a pull request, or support a deployment workflow.

When to use this guide

This guide applies when your project code is hosted in GitHub and the support team needs repository access to perform technical support work.

Typical cases include:

• bug fixes in application code;
• analytics, tracking, ecommerce, or tag implementation that requires code changes;
• theme, plugin, frontend, backend, or API repairs;
• reviewing build, test, or deployment failures;
• creating a branch and pull request for your team to review;
• preparing a staging or preview deployment from a pull request.

Preferred workflow

The support team normally works through a repository-first workflow:

1. You invite the support team to the relevant GitHub repository with limited access.
2. The support team reviews the repository, project instructions, build commands, and current issue.
3. The support team creates a branch for the agreed task.
4. We implement and validate the fix where possible.
5. We open a pull request with a summary of changes and verification notes.
6. You or your team review the pull request.
7. The change is tested on staging, preview, or another safe environment before production whenever possible.
8. Production deployment happens only after the required approval.

Before you invite the support team

Please prepare the following information in the ticket:

• GitHub repository URL;
• repository owner or organization name;
• main production branch, such as main, master, or production;
• staging, development, or preview branch, if one exists;
• staging or preview URL, if available;
• short description of the issue and expected result;
• runtime versions, such as PHP, Laravel, Node.js, Python, Ruby, Java, or other stack details;
• package manager and install command, such as npm, pnpm, yarn, composer, pip, or poetry;
• build, test, lint, and formatting commands;
• deployment method, if GitHub is connected to staging or production deployment;
• the person who can approve production deployment, if production deployment may be needed.

Recommended GitHub role

For most repair tasks, the correct GitHub permission is Write on one specific repository.

• Read: suitable for a code audit, diagnostics, or review without code changes.
• Triage: suitable for issue management only. It is usually not enough for code repair.
• Write: recommended for normal support work. It allows the support team to create branches, push commits, open pull requests, and participate in code review.
• Maintain: not required by default. It may be considered only when repository-level maintenance actions are part of the agreed task.
• Admin: not required by default. It should be avoided unless the task specifically requires repository settings, protected branches, webhooks, GitHub Actions configuration, secrets, environments, or deploy keys and you approve that scope.
• Organization Owner: not needed for normal support work and should not be granted.

How to invite the support team to a repository

The exact GitHub interface may differ depending on whether the repository belongs to a personal account, organization, or GitHub Enterprise workspace. In most cases, the process is:

1. Open the relevant GitHub repository.
2. Go to Settings.
3. Open Collaborators, Manage access, or the equivalent access section for your organization.
4. Invite the support team GitHub user or team provided in your ticket.
5. Select Write permission unless support requested a different minimum permission for a specific reason.
6. Confirm the invitation.
7. Reply in the ticket with the repository URL and the branch that should be used for the work.

Branch and pull request safety

Please keep the production branch protected whenever possible.

A safe repository setup usually includes:

• no direct pushes to main, master, or the production branch;
• pull requests required before merge;
• at least one review required for production changes;
• CI checks required before merge where practical;
• separate staging or preview deployment before production deployment;
• clear rollback or revert procedure for risky changes.

Make the repository ready for Codex-assisted work

The support team may use Codex-assisted development to review the codebase, prepare changes, run checks, and create pull requests. To make this faster and safer, the repository should contain clear project instructions.

If these files or details do not exist yet, the support team may add or propose them in a pull request:

• AGENTS.md with repository-specific instructions for Codex and engineers;
• README.md or DEVELOPMENT.md with setup instructions;
• .env.example with variable names but without real secrets;
• runtime version files such as .nvmrc, .node-version, .php-version, composer.json, or similar stack files;
• documented build, test, lint, format, and migration commands;
• known limitations, failing tests, or local setup notes.

Do not put production secrets in GitHub or Codex instructions

Please do not add production secrets to GitHub issues, pull request comments, AGENTS.md, README.md, .env.example, or ordinary ticket messages.

Examples of secrets that should not be shared this way include:

• production .env files;
• database passwords;
• API secrets and private keys;
• Stripe live secret keys;
• SMTP passwords;
• SSH private keys;
• GitHub personal access tokens;
• cloud provider keys;
• payment, advertising, CRM, or analytics platform secrets.

For development and Codex-assisted work, use fake, local, test, or staging-only values whenever possible.

If GitHub Actions deploys your project

If your repository uses GitHub Actions for deployment, please tell the support team how staging and production are deployed.

A safe setup usually includes:

• a staging or preview deployment target for pull request testing;
• a separate production deployment target;
• production deployment approvals through GitHub Environments or your existing release process;
• production secrets stored inside the deployment environment, not in repository files or ticket messages;
• deployment restricted to approved branches;
• logs available for review without exposing secrets.

If repository settings, GitHub Actions secrets, deployment environments, branch protection, or webhooks must be changed, the support team will request explicit approval and explain whether temporary elevated access is needed. In many cases, the support team can provide step-by-step instructions for your repository administrator to apply instead.

Fine-grained personal access tokens

Repository invitations are preferred. Use a token only when an invitation, team access, GitHub App, or deploy key is not suitable for your setup.

If a token is unavoidable, create a fine-grained personal access token limited to the selected repository and the shortest practical expiration period. For typical code repair, the minimum permissions are usually:

• Repository access: only the selected repository;
• Contents: read/write if the support team must push a branch;
• Pull requests: read/write if the support team must open or update a pull request;
• Actions: read if the support team needs to inspect workflow runs;
• Workflows: write only if editing workflow files is part of the agreed task;
• Administration, secrets, organization, and billing permissions: do not grant unless the support team explicitly requests them for a defined reason.

Send tokens only through the secure method agreed in the ticket. Revoke the token after the task is completed.

Deploy keys

A deploy key may be appropriate when your server needs to pull code from one GitHub repository. It is not the standard way to give the support team human support access.

If a deploy key is used:

• use a separate key for the specific repository;
• keep it read-only unless write access is explicitly required and approved;
• store the private key only on the deployment server or approved secure system;
• remove the deploy key when it is no longer needed;
• do not reuse the same deploy key across unrelated repositories.

If multiple repositories are involved

Some projects use separate repositories for frontend, backend, infrastructure, theme, plugins, packages, or deployment scripts. Please list all repositories that are relevant to the issue and explain how they interact.

Grant access only to repositories required for the task. If the issue can be fixed in one repository, do not grant access to the entire organization.

If external GitHub access is not allowed

If your security policy does not allow inviting external users, the support team can often work in a client-executed mode. In this mode, your team provides a repository export, redacted files, logs, screenshots, or specific code excerpts, and the support team provides a patch, pull request guidance, or step-by-step instructions for your team to apply.

This mode can be safer for restricted organizations, but it usually requires more communication and may slow down diagnostics or verification.

After the ticket is completed

When the agreed work is completed, please review and revoke access that is no longer needed.

1. Remove the support user or team from the repository if ongoing support is not active.
2. Revoke temporary fine-grained tokens.
3. Remove deploy keys that are no longer required.
4. Review GitHub Actions environment access, secrets, and deployment permissions.
5. Rotate any token, key, or secret that was shared directly instead of through an invitation-based method.
6. Keep the pull request, commit history, and ticket notes for audit and warranty reference.

Quick checklist

• Invite the support team only to the repository involved in the ticket.
• Use Write permission for normal code repair.
• Keep production branches protected.
• Use pull requests and staging or preview deployments where possible.
• Do not share production secrets in GitHub, email, chat, or documentation files.
• Use fine-grained tokens only when invitations are not possible.
• Use read-only deploy keys unless write access is explicitly required.
• Revoke temporary access after the ticket is completed.