[cooktheryan]

Human merge required. Agents must not merge this RFC or enable automatic merging. A human must manually click Merge.

Summary

• Propose GitLab.com repository credentials through the protected credential path, preserving the existing Repo capability and Agent workflow.
• Limit each Installation to one Git provider for this release. A revision that combines GitHub and GitLab bindings is rejected.
• Treat a possibly-sent draft merge-request create as unresolved: never automatically repeat the POST, and require an authorized operator to reconcile only from evidence tied to the exact operation.
• Require attributable audit evidence for successful writes, denials, and uncertain upstream outcomes, without PATs or request bodies.
• Expand the implementation plan with lost-response, audit-persistence, mixed-provider, and workflow verification requirements. The operator reconciliation surface remains an open implementation decision.

Research

The GitLab scope remains GitLab.com project service accounts and fine-grained PATs. The proposal keeps the existing Git access profiles as a starting point, limits draft merge requests to already-pushed branches, and excludes merge, approval, project administration, and pipeline control. The supported token creation and rotation path remains an open decision. This spike compared published GitLab documentation and repository source; it did not run live GitLab operations.

Sources: GitLab service accounts, fine-grained PATs, Git permissions, REST permissions, service-account token API, and GraphQL token creation.

Verification

• git diff --check and the repository’s full Prettier pre-push check passed for this update.
• node scripts/check-specs.mjs could not run because @sindresorhus/slugify is unavailable in this worktree. No dependencies were installed.
• No product tests or live GitLab operations were run; this update changes specifications only. Runtime qualification remains untested.

Review focus

• Which GitLab PAT source should the first release use: a live static secret or a prepared-token provider?
• Is the supported fine-grained PAT creation and rotation flow acceptable for a project service account?
• Which exact GitLab API operations and audit details do the selected profiles require?
• Where should an authorized operator reconcile an unresolved draft-create result: through the Console, through a CLI/support procedure, or in a later implementation milestone?
• What real-runtime evidence is required before enabling the protected OpenShell path?

RFC numbering

The updated base is 98785b43abf9c83ea4ad6c08dfc385e87bbbf836, which ends at RFC-0023, so this proposal uses RFC-0024. PR #3050 also currently uses RFC-0024; unmerged proposals do not reserve IDs, so reconcile both against main before either merges. This PR requests architectural feedback and does not claim acceptance.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[freeqaz-openai]

heads up that we are about to land some major changes around how credentials + providers are implemented, so I'd recommend taking a look at that. #2484

[cooktheryan]

hold until further guidance from #2484

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR proposes GitLab.com repository credentials through the existing Repo and protected credential path, with an implementation plan.

Example: An Agent needs to push a branch and open a draft merge request in GitLab.com project 42.

• Before: The supported repository credential workflow selects GitHub and cannot bind that GitLab project.
• After: The proposal would authorize those operations for the bound project without giving the Agent its PAT.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	A coherent architecture proposal with no actionable specification defect; overall readiness remains limited by explicit design choices awaiting owner resolution.
Proof confidence	🌊 off-meta tidepool	Not applicable: This is a specification-only RFC with no implemented GitLab path; the inspected screenshots show setup context, and the plan explicitly leaves real Agent, GitLab, denial, withdrawal, and lost-response qualification for implementation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Feature · Worth it: Needs a maintainer decision
User problem: Teams whose source lives in GitLab cannot bind those projects through the supported Agent repository credential workflow.
Reason: The capability has a concrete use case and active owner involvement, but the remaining credential and recovery choices require the focused decision recorded above.

Merge readiness

⛔ Blocked before merge - 1 item remains

Keep this PR open for maintainer design review: GitLab repository access remains missing, the proposal has active owner participation, and no actionable defect was found in the specification changes.

Priority: P3
Reviewed head: daee15b62c38493ab71a29e7decb72a883b67e75
Owner decision: Required. See Decision needed.

Decision needed

• Question: Which first-release PAT source and supported creation, rotation, and unresolved-create reconciliation contract should this GitLab proposal adopt?
• Recommendation: Continue focused RFC review: Keep the proposal open while validating a supported service-account token flow and selecting the credential and reconciliation owners.
• Why: Owner edits establish the single-provider scope, but neither the discussion nor the specifications select these remaining implementation contracts.

Before merge

• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

OCC admits repository bindings and owns their lifecycle; provider adapters and the selected Credential Proxy authenticate permitted outbound operations while keeping provider credentials outside the Agent.

flowchart TB
  Operator[Operator] -.->|proposed project binding| OCC[OCC admission and grants]
  Source[Selected PAT source] -.->|proposed protected delivery| Proxy[Credential Proxy]
  Agent[Agent in paired Sandbox] -.->|proposed repository request| Proxy
  Proxy -.->|checks current authority| OCC
  Proxy -.->|authorized operation| GitLab[GitLab project]

Loading

Technical review

Best possible solution:

Resolve the credential lifecycle and recovery contract in this RFC, then implement GitLab through the existing Repo and protected-delivery owners.

Do we have a high-confidence way to reproduce the issue?

This is a feature proposal rather than a bug report; current-main composition independently confirms that supported repository credentials select GitHub.

Is this the best way to solve the issue?

Extending the existing Repo and protected credential owners fits the architecture and avoids a parallel broker; the proposal appropriately separates design, implementation, and runtime qualification.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 250d3234bae3.

Provenance checked

• RFC index and existing credential architecture keeps the original intent (3115679: The merged Credential Proxy implementation separates OCC approval and delivery state, provider policy, token custody, and protected sending; the index update registers a new proposal without replacing those owners.)

Security

None.

Evidence

What I checked:

• Exact introduced change: The pinned introduction contains only the RFC, its linked implementation plan, and an index update; it changes no executable code, stored-data format, or Driver interface. (specs/rfcs/0024-gitlab-repository-credentials.md:2, daee15b62c38)
• Current main remains GitHub-specific: Repository composition explicitly requires the github implementation and constructs GitHub policy and registry owners; the shared runtime files also retain gh-specific entries. (apps/controller/src/composition/repository-credentials/platform.ts:45, 250d3234bae3)
• Implemented architecture and qualification boundary: The authoritative design distinguishes implemented protected-execution composition from the bundled OpenShell release, which cannot yet enforce that path; this PR preserves that qualification limit. (docs/design.md:32, 250d3234bae3)
• Maintainer participation and settled scope: Free invited revision after Credential Proxy landed in RFC-0024: Support GitLab.com repository credentials #3137 (comment) and subsequently edited the proposal to exclude multi-provider configuration; the reviewed head preserves that scope. (specs/rfcs/0024-gitlab-repository-credentials.md:31, b6c6aa510e13)
• Explicit implementation decisions: The plan leaves PAT sourcing, supported creation and rotation, exact API operations, and authorized reconciliation ownership open while specifying no automatic retry after a possibly-sent create. (specs/plans/0024-gitlab-repository-credentials.md:54, daee15b62c38)
• Linked request and canonical search: Support GitLab repositories in repository credentials #3135 explicitly requests this provider and links this RFC; repository-wide GitLab search found no separate implementation PR owning delivery.

Labels

Label changes:

No label changes.

Label justifications:

• P3: This is a specification-only proposal for an optional provider, with no current GitHub regression or runtime change.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (2 earlier review cycles)

• reviewed 2026-10-21T19:38:46.495Z sha 9c049f9 :: blocked before merge. :: none
• reviewed 2026-10-23T19:23:01.748Z sha 8d3cf7c :: blocked before merge. :: none

Reviewed October 26, 2026, 11:41 AM ET / 15:41 UTC (Revision 3).

[freeqaz]

Free's clanker here (an AI agent working on Free's behalf). Since you were holding for #2484: it has landed as RFC-0023 (Credential Proxy), and the implementation (#2487) is on main too. This branch now conflicts with main in specs/README.md, so CI won't run on a new head until main is merged in.

The RFC and plan will also need a new number, since 0023 is taken on main. Open PRs already claim 0024 (#2755, #3050, #3230) and 0025 (#3233), and check-specs requires numbers to run continuously from main's highest, so the right number depends on which of those lands first.

[cooktheryan]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/40011273835
• Updated: 2026-10-23T19:25:41.982Z

[freeqaz-openai]

Human Free here: Credential Proxy landed and I'm cleaning it up now, but main should be in a good enough state now to revise this. I'll likely make a pass at this really quick just to get something in place, but please feel free to revise or gut. :)

[cooktheryan]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/40352036241
• Updated: 2026-10-26T15:43:25.256Z

[cooktheryan]

@freeqaz I'm back and forth on mixing providers in an install. I updated right now for only one provider but I could see how mixed would be valuable so open to any changes or feedback