Add support orgo as provider

[zozo123]

https://www.orgo.ai/

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 2, 2026, 9:18 PM ET / 01:18 UTC.

Summary
Keep open: current main and v0.34.0 still do not include Orgo provider support, and the linked implementation PR remains open, conflicting, and gated on maintainer product acceptance plus real hosted Orgo lifecycle proof.

Reproducibility: not applicable. this is a provider feature request, and current-main source inspection shows Orgo is absent rather than malfunctioning.

Root-cause cluster
Relationship: canonical
Canonical: #449
Summary: This issue is the provider-support tracking request; the linked open PR is the current implementation candidate but has not landed.

Members:

• fixed_by_candidate: feat: add Orgo provider #458 - The PR is linked from the issue discussion and adds the Orgo provider implementation, docs, config, tests, and live-smoke wiring.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The concrete implementation candidate already exists, but resolution depends on maintainer product acceptance, conflict refresh, and hosted Orgo credential proof rather than a new autonomous fix PR.

Review details

Best possible solution:

Keep the issue open until maintainers either land a refreshed Orgo provider PR with hosted lifecycle proof and accepted credential boundaries, or decide that Orgo support should not be built in.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a provider feature request, and current-main source inspection shows Orgo is absent rather than malfunctioning.

Is this the best way to solve the issue?

Unclear as an implementation direction until maintainers accept built-in Orgo support and the linked PR supplies real hosted lifecycle proof with redacted credentials.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Built-in Orgo support remains a product and credential-boundary decision, and the open candidate has not provided redacted hosted lifecycle proof with real Orgo credentials.
• The linked implementation candidate is currently conflicting, so maintainers need a refreshed PR or an explicit decision to close it before resolving the issue.

Codex review notes: model internal, reasoning high; reviewed against 79c985cbf114.

Label changes

Label changes:

• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• remove clawsweeper:linked-pr-open: Current issue advisory state no longer selects this label.

Label justifications:

• P3: Adding a new hosted provider is useful but speculative and is not a regression in existing Crabbox behavior.
• impact:auth-provider: The request adds a new provider and therefore affects provider routing and credential handling.

Evidence reviewed

What I checked:

• AGENTS.md policy read: Read the full 45-line AGENTS.md; its provider-adapter boundary and secret-handling guidance apply to evaluating a new hosted provider. (AGENTS.md:13, 79c985cbf114)
• No Orgo implementation on current main: A repository-wide search for Orgo names and expected credential prefixes found no Orgo provider, docs page, config section, or environment variable on current main. (79c985cbf114)
• Provider registry lacks Orgo: The built-in provider registry imports the current provider set and has no Orgo import. (internal/providers/all/all.go:4, 79c985cbf114)
• Provider docs lack Orgo: The generated provider matrix documents 69 current built-in providers and does not list Orgo. (docs/providers/README.md:64, 79c985cbf114)
• Latest release lacks Orgo: Searching v0.34.0 for Orgo only found unrelated substrings such as 'forgotten' and 'ForGOOS', not provider support. (ef898c27570a)
• Open implementation candidate: GitHub PR metadata shows feat: add Orgo provider #458 is open and conflicting; it adds internal/providers/orgo, docs, config, tests, and live-smoke wiring, but its body and maintainer comments keep hosted lifecycle proof as the remaining gate. (8cb00c22c529)

Likely related people:

• zozo123: Local history shows prior merged provider additions by Yossi Eliaz, and the linked Orgo PR is authored from the same GitHub account. (role: prior provider implementation contributor and Orgo proposer; confidence: high; commits: 3b92643ab361, 7575c39aa3ff, 48939ed52ee3; files: internal/providers/opencomputer, internal/providers/smolvm, internal/providers/azuredynamicsessions)
• vincentkoc: The issue and PR comments identify Vincent Koc as the reviewer carrying the validation/proof gate, and local history shows recent provider smoke and validation work. (role: recent provider validation and review contributor; confidence: high; commits: 86c123d86315, 6e88b11d105e, e2fc2adcdb86; files: scripts/live-smoke.sh, scripts/live-smoke.test.js, internal/cli/credential_provenance.go)
• steipete: Local history shows recent provider additions and OpenComputer secret-redaction work, and the linked Orgo PR includes several steipete commits aligning credentials, cleanup, readiness, and provider capabilities. (role: recent adjacent provider and credential-boundary contributor; confidence: high; commits: ef898c27570a, cb83fcfc0030, e240d47a700b; files: internal/providers/all/all.go, internal/providers/opencomputer, internal/providers/orgo/backend.go)
• coygeek: Local history shows several recent built-in provider additions touching provider registration and adjacent provider infrastructure. (role: recent provider infrastructure contributor; confidence: medium; commits: 4003a3000972, 460e241d1b71, a71c8a3a29aa; files: internal/providers/all/all.go, internal/providers/coder, internal/cli/config.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[vincentkoc]

@clawsweeper re-review

Implementation candidate now exists: #458.

Current PR state:

• head 8cb00c22c5297179e574940ebe2c142f1dc6b0c2
• public CI is green: https://github.com/openclaw/crabbox/actions/runs/28111473550
• local validation and fake-API lifecycle coverage are recorded in the PR body

Still not closing this issue or merging the PR yet. The remaining gate is maintainer/product acceptance of built-in Orgo support plus redacted hosted Orgo lifecycle proof with real credentials: create workspace/computer, wait until running, execute command, delete computer/workspace, and show no leaked token/output.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.