[adilhafeez]

MARSOHS-1808

What

The API now accepts agent: sandbox as an equal spelling of agent: none for a session with no agent in it, and stores new bare sandboxes as AGENT_KIND_SANDBOX instead of AGENT_KIND_NONE. The API also renames the flat manifest key from agent to harness, with agent kept as its original name. doctl now generates and documents harness: none, accepts either key and both spellings, and recognizes both agent kinds.

$ doctl harness-runtime create --template sandbox --name eval-01 --dry-run
harness: none
name: eval-01
template: coding-base

• Generated manifests (--harness, --template sandbox, or a lone --template) write harness: instead of agent:, and the create, config create and validate help lead with harness, noting agent as its original name.
• Bare-sandbox checks accept both spellings: --harness none and --harness sandbox are refused with the existing pointer to --template sandbox, and launch refuses a manifest with either.
• Validation accepts both none and sandbox with no warning.
• harness key: validation, bare-sandbox detection and the OpenAI-agents path read harness or agent. A manifest that sets both is an error (set "harness" or "agent", not both), a missing key reports "harness" as required, and adapter errors name the key the author wrote.
• Agent kinds: doctl treats both AGENT_KIND_NONE and AGENT_KIND_SANDBOX as a bare sandbox (ready card, startup wording) and displays both as None. godo has no constant for the new value yet, so hostedAgentKindSandbox is defined locally in commands/agents_run.go.

Release order

This build must ship after the server accepts the harness key. A server from before the rename rejects harness as an unknown field, so every create that builds its manifest (--harness, --template) would fail with a 400; hand-written agent: manifests would still work.

Why it matters for released versions

Released doctl does not know AGENT_KIND_SANDBOX. Once the server writes it, released doctl shows a new bare sandbox with the managed-agent ready card (label agent, offering launch). This build fixes that, so it should ship close to the server change.

Testing

• go test ./commands/: all tests touched here pass. TestRegistryLogin, TestRegistryLogout and TestRefreshExpiredOAuthToken fail identically on an unmodified main checkout on this machine.
• Against a local server stack that includes the server-side change: create --template sandbox generated agent: none (before the generator switch; --dry-run now prints harness: none), the session was stored as AGENT_KIND_SANDBOX, the ready card showed Agent None with the exec, upload, download and port-forward steps, and exec ran in the guest.
• Same stack with the harness key: validate accepted harness: none and rejected a file with both keys; create --spec with harness: none and --prompt was refused before any session existed; without --prompt it created a ready AGENT_KIND_SANDBOX session.

[kerickson-dot]

The description says switching the generator and --spec help text from agent to harness is a follow-up once the server ships. Is there an issue tracking that? The docs (digitalocean/product-docs#6855) will lead with harness: once this ships, so the CLI help and the docs will disagree until the follow-up lands.

[adilhafeez]

The description says switching the generator and --spec help text from agent to harness is a follow-up once the server ships. Is there an issue tracking that? The docs (https://github.com/digitalocean/product-docs/pull/6855) will lead with harness: once this ships, so the CLI help and the docs will disagree until the follow-up lands.

Thanks @kerickson-dot for looking at it - we will want to lead with harness: but still keep agent: for backward compatibility. I will update the PR.