What problem are you trying to solve?
Repository checkout support accepts an opaque credential_provider_ref and exposes an in-process resolveRepositoryCredentials hook. This works for applications embedding TrueForge, but the standalone server has no way to configure that hook.
Consequently, standalone deployments can clone public repositories but cannot resolve credentials for private or writable repositories.
Proposed solution
Add an optional, provider-neutral external credential resolver for the standalone server.
When a session repository includes credential_provider_ref, the server should:
- Call an operator-configured resolver endpoint immediately before provisioning or resuming the sandbox.
- Send only the opaque reference and repository metadata required for authorization.
- Receive short-lived Git credential-store content compatible with the existing sandbox credential helper.
- Keep resolved credentials in memory only and discard them after sandbox initialization.
- Resolve again for later turns so credentials can be refreshed without recreating the session.
- Fail closed when the resolver is unavailable, rejects the request, or returns an invalid response.
The transport should include bounded timeouts, cancellation, response-size limits, configurable authentication, and redaction-safe errors. Request and response bodies must not be logged, persisted, emitted as events, or exposed through the API.
The existing in-process resolver interface should remain available for embedded deployments. The external adapter should be opt-in; deployments without one should retain the current rejection behavior.
Alternatives considered
- Add provider-specific GitHub credentials directly to TrueForge. This would couple repository checkout to one provider and require TrueForge to hold provider root credentials.
- Accept raw credentials in session or turn requests. This risks credentials entering request logs, traces, persisted payloads, and client-visible schemas.
- Require every deployment to embed TrueForge. This prevents the packaged standalone server from supporting private repository checkout.
- Persist resolved credentials with the session. This increases exposure and prevents safe short-lived credential refresh.
Additional context
This builds on #556 and the repository-checkout implementation in #559. That work provides the repository resource, opaque provider reference, sandbox credential helper, and in-process resolver contract. This issue covers exposing that contract safely for standalone deployments.
What problem are you trying to solve?
Repository checkout support accepts an opaque
credential_provider_refand exposes an in-processresolveRepositoryCredentialshook. This works for applications embedding TrueForge, but the standalone server has no way to configure that hook.Consequently, standalone deployments can clone public repositories but cannot resolve credentials for private or writable repositories.
Proposed solution
Add an optional, provider-neutral external credential resolver for the standalone server.
When a session repository includes
credential_provider_ref, the server should:The transport should include bounded timeouts, cancellation, response-size limits, configurable authentication, and redaction-safe errors. Request and response bodies must not be logged, persisted, emitted as events, or exposed through the API.
The existing in-process resolver interface should remain available for embedded deployments. The external adapter should be opt-in; deployments without one should retain the current rejection behavior.
Alternatives considered
Additional context
This builds on #556 and the repository-checkout implementation in #559. That work provides the repository resource, opaque provider reference, sandbox credential helper, and in-process resolver contract. This issue covers exposing that contract safely for standalone deployments.