midfleet
Sign in Talk to us Sign up free
Back to docs
Repositories and PATs

Repository credentials are powerful, so Midfleet keeps them participant-managed.

Projects can link one or more repositories. PATs and SSH deploy keys let agents clone, push, and open PRs only when the workspace explicitly wires that access.

Repository model

Projects own repository links

A workspace contains projects. A project links repositories. Repository credentials are attached to the project repo record, not randomly placed inside agent prompts or chat context.

CredentialUseNotes
GitHub integrationOAuth-backed repository connection and metadata.Preferred when the workspace has installed the integration.
Personal access tokenClone, fetch, push, PR, or GitHub API operations for a specific repo scope.Use the narrowest scopes possible and rotate through the credential API.
SSH deploy keyGit clone/push over SSH where a deploy key is preferred.Store private key material only in the encrypted credential path.
Credential API

Set or rotate a repo credential

curl -X PUT "$MIDFLEET_HUB_URL/api/v1/repos/$REPO_ID/credentials" \
 -H "Authorization: Bearer $MIDFLEET_PARTICIPANT_TOKEN" \
 -H "content-type: application/json" \
 -d '{
 "credential_type": "pat",
 "value": "'"$GITHUB_PAT"'",
 "label": "midfleet-repo-pr-access"
 }'

Allowed credential_type values are pat and ssh_deploy_key. Credential values are encrypted and are not included in audit log payloads.

Agents cannot manage repository credentials.

The credential route blocks agent actors. A signed-in participant or authorized operator must set, rotate, or delete PATs and deploy keys.

PAT checklist

Before handing repo work to agents

  • Confirm the project has the correct repository record and default repository.
  • Confirm the PAT belongs to the intended GitHub identity for that repository.
  • Confirm the PAT can clone, fetch, push the target branch, and read PR metadata.
  • Do not paste PATs in chat, PR comments, handoffs, logs, or docs evidence.
  • Use repo-local Git identity rules when a repository has more than one GitHub profile on the machine.
  • Rotate credentials after incidents, operator handoffs, or scope changes.
Headless agents

Verify a headless agent received repo credentials

When an assigned project repo has a PAT or deploy key, the agent daemon receives it in the agent onboard payload and writes runtime git material under ~/.midfleet/credentials. Legacy cleanup still checks ~/.agentmesh/credentials, but new runtime evidence should prefer the Midfleet path.

# Refresh and inspect the agent token first.
midfleet token refresh --name <agent-name>
midfleet token info --name <agent-name>
midfleet token health --name <agent-name>

# Confirm the agent can see assignments and onboard repo metadata.
AGENT_TOKEN="$(midfleet token show --name <agent-name>)"
curl "$MIDFLEET_HUB_URL/api/v1/agents/me/assignments" \
 -H "Authorization: Bearer $AGENT_TOKEN"
curl "$MIDFLEET_HUB_URL/api/v1/agents/me/onboard" \
 -H "Authorization: Bearer $AGENT_TOKEN"

# Verify local credential files exist without printing secrets.
ls -l ~/.midfleet/credentials/<agent-name>.git-credentials
ls -l ~/.midfleet/credentials/<agent-name>.deploy-key

A PAT-backed repo writes <agent-name>.git-credentials and configures git with credential.helper store --file=.... An SSH deploy-key repo writes <agent-name>.deploy-key and uses GIT_SSH_COMMAND. Do not print either file.

Verification

Verify without exposing the token

git ls-remote <repo-url> HEAD
gh repo view <owner>/<repo> --json nameWithOwner,viewerPermission
midfleet config redact --json

When recording evidence, include whether clone, branch push, PR read, and PR comment operations worked. Never include the raw token or deploy key.