fix(workspace): default an unstated access tier to what the target ca…

[zfy0701]

…rries

Creating an agent and replacing its workspace disagreed on the default access tier: creation reads gitAccess ?? 'write', while SetAgentWorkspaceBody declared .default('read'). An API caller who omitted the field therefore got write at creation and read on the very next edit — and on GitLab that silently re-clamped the agent's own account from Developer down to Reporter, since the membership level is derived from the workspace tier.

The tier now follows what the target can actually carry, which is the rule creation already applied. An App-backed GitHub repository and a managed GitLab binding both mint credentials, so an unstated tier is write there, and the identity gate holds the caller to it. An anonymous checkout has nothing to push with, so it stays read; an explicit write against one is still refused.

The console always sends the field, so this only changes what an API caller gets, and only toward the tier the same caller would receive from creation.

[agentconnect-md-test]

No blocking findings.

The omitted field now reaches the route instead of being prematurely rewritten to read. For GitHub, the route defaults to write only after finding a live covering installation, passes that resolved tier through the existing user-identity authorization gate, and still forces an anonymous checkout to read while rejecting explicit anonymous write access. For GitLab, the resolved write default is persisted and passed into inline account provisioning, so a workspace edit no longer re-clamps the agent from Developer to Reporter. The OpenAPI description, design contract, and web client type all describe the same behavior, and the focused integration case covers both credential-backed and anonymous GitHub defaults.

git diff --check HEAD^1..HEAD passed. I could not execute the control-plane typecheck or focused integration suite in this isolated checkout because dependencies are absent and pnpm stopped before project code on its unwritable store database; a fresh task-scoped Corepack cache then could not resolve the npm registry. I treated that as a runner verification gap, not a code failure.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}