feat(cloud-agent-next): keep managed Git credentials out of sandboxes

[eshurakov]

Summary

• Replace sandbox-visible managed GitHub and GitLab credentials with short-lived encrypted capabilities redeemed by git-token-service through sandbox outbound interception.
• Bind capabilities to the repository, provider auth surface, selected credential identity, and outer Sandbox Durable Object container ID so replay from another sandbox fails closed before provider lookup.
• Preserve staged rollout compatibility for legacy unbound capabilities during the one-hour lifetime window, and propagate Cloudflare runtime HTTPS-interception trust into nested DIND devcontainers.
• Add standard and DIND outbound rewrite probes plus focused coverage for capability issuance, redemption, redirects, LFS paths, GitLab CLI surfaces, and replay rejection.

Verification

• Manually exercised the real-Git outbound rewrite probes for standard sandbox and DIND containment paths during implementation.
• Did not rerun manual probes during the final history cleanup; no UI or visual surface changed.

Visual Changes

N/A

Reviewer Notes

• Deploy in order: provision the SCM capability secret, deploy rollout-compatible git-token-service, then deploy cloud-agent-next.
• Remove temporary unbound kgh1.* / kgl1.* issuance and redemption support after the one-hour compatibility window.
• GitLab intentionally allows broad authenticated /api/v4/** and /api/graphql access for glab; Git smart HTTP and LFS control paths remain repository-bound.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental commit (41b2b497e) resolves the sole remaining WARNING by introducing a dedicated 'integration_identity_missing' error code when getGitLabSessionIdentity returns null, replacing the misleading 'no_token' mapping. The fix is complete: type union updated in both git-token-service and cloud-agent-next, user-facing message added to gitLabTokenLookupFailureMessage, and a targeted test case confirms the new behavior.

Resolved Issues

File	Line	Issue	Status
services/git-token-service/src/index.ts	832	getGitLabSessionIdentity returning null was mapped to reason: 'no_token' (misleading — actual cause is missing integration identity, not missing token)	✅ Fixed in 41b2b497e

Files Reviewed (5 files in incremental diff)

• services/git-token-service/src/index.ts — WARNING resolved
• services/git-token-service/src/index.test.ts — new test coverage for integration_identity_missing
• services/cloud-agent-next/src/types.ts — 'integration_identity_missing' added to IssueGitLabSessionCapabilityResult union
• services/cloud-agent-next/src/session-service.ts — user-facing message case added
• services/cloud-agent-next/src/session-service.test.ts — test case for the new message

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 270,476 tokens}

_{Review guidance: REVIEW.md from base branch main}

[pandemicsyn]

lgtm, one thing inline. Based on the PR body not entirely sure if this is actually breaking the implied security contract or not.

[pandemicsyn]

Ok robot flagged this:

"v2 GitHub capabilities are host-scoped rather than repo/path-scoped during redemption, allowing sandbox code to exchange a repo capability for a real token on any allowed GitHub host endpoint that the underlying token can access.

So a capability issued for acme/repo can be redeemed for requests like:

• https://api.github.com/graphql
• https://api.github.com/user/repos
• https://api.github.com/repos/acme/other/...
• https://uploads.github.com/repos/acme/other/...
• https://github.com/acme/other.git/...
  ”

I think its interpreting that as a regression based on this comment in the PR body:

Bind capabilities to the repository, provider auth surface, selected credential identity, and outer Sandbox Durable Object container ID so replay from another sandbox fails closed before provider lookup.