How to Give Metricfixer Safe GitHub Access

Use this guide when Metricfixer 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 Metricfixer 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

Metricfixer normally works through a repository-first workflow:

1. You invite Metricfixer to the relevant GitHub repository with limited access.
2. We review the repository, project instructions, build commands, and current issue.
3. We create 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 Metricfixer

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 Metricfixer work. It allows us 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 Metricfixer 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 Metricfixer GitHub user or team provided in your ticket.
5. Select Write permission unless Metricfixer 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

Metricfixer 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, Metricfixer 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 us 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, we will request explicit approval and explain whether temporary elevated access is needed. In many cases, we 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 Metricfixer must push a branch;
• Pull requests: read/write if Metricfixer must open or update a pull request;
• Actions: read if Metricfixer 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 Metricfixer 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 Metricfixer 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, Metricfixer 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 we provide 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 Metricfixer 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 Metricfixer 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.