Wait for complete sandbox credentials before connecting

[Osvaldo Ortega (osortega)]

Connecting to a freshly provisioned sandbox could leave the session unable to make authenticated requests. Nothing about it looked like a failure — the relay opened, the handshake completed, the connection registered — but every session request against it then failed.

The credentials a new environment returns can be incomplete for a short window after it comes up.

What this does

Re-mints credentials until they are complete.

The bound is derived, not guessed. It is sized to cover the backend's own registration retry cycle, so a warm environment succeeds on the first mint and never enters the loop.

It degrades rather than failing. An environment may legitimately never return the missing piece, and a session with reduced capability beats refusing to connect at all. The last credentials are used either way, and the degraded case is logged so the cause is visible rather than leaving only downstream symptoms to puzzle over.

If the environment drops back to "waking" mid-wait, the loop stops rather than re-entering the wake path; the handshake watchdog already covers a host that has gone away. A transient failure while re-minting is also non-fatal — the credentials already in hand are used instead of discarding them.

Risk

Only reachable when the initial credentials are incomplete, which is the broken case today. A warm environment takes the same path it always did.

Validation

• npm run typecheck-client, eslint on both changed files
• ./scripts/test.sh --glob "**/cloudSandboxAgentHostService.test.js" — 7 passing, covering: re-mint until complete, give up and connect anyway, no re-mint when the first mint is already complete, a value that is present but unusable, a failed re-mint, and the environment returning to waking mid-wait.

Each behavioural change was checked against the case it is meant to handle by reverting it and confirming the matching test fails.

[Copilot]

Pull request overview

Adds bounded credential re-minting while waiting for a sealed GitHub token.

Changes:

• Retries /connect up to 12 times.
• Falls back to the latest credentials.
• Adds focused unit tests.

Show a summary per file

File	Description
cloudSandboxAgentHostService.ts	Implements sealed-token waiting and diagnostics.
cloudSandboxAgentHostService.test.ts	Tests successful, exhausted, and unnecessary retries.

Review details

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Suppressed comments (2)

src/vs/sessions/contrib/providers/remoteAgentHost/browser/cloudSandboxAgentHostService.ts:248

• This method JSDoc repeats implementation and failure history rather than concisely documenting the contract. Reduce it to 1–2 sentences per the repository comment guidelines.

	/**
	 * Re-mint credentials until they carry a sealed GitHub token.
	 *
	 * A newly provisioned environment answers `/connect` as soon as the compute is up, which can be
	 * before Mission Control has learned the host's sealing key. The credentials are valid, but

src/vs/sessions/contrib/providers/remoteAgentHost/test/browser/cloudSandboxAgentHostService.test.ts:115

• This inline comment also exceeds the one-line limit. Keep only the non-obvious reason for the + 1 expectation.

		// Bounded rather than an unbounded loop, and the connection still proceeds without a
		// sealed token. The initial mint plus one re-mint per retry.

• Files reviewed: 2/2 changed files
• Comments generated: 5
• Review effort level: Balanced