Skip to content

Commit 9182a02

Browse files
committed
Add OpenClaw as a new provider for OK Code
- Introduce a detailed rollout plan for integrating OpenClaw as a third provider alongside Codex and Claude. - Define phases for architecture groundwork, UI integration, MVP adapter implementation, and future enhancements. - Update relevant files and settings to accommodate OpenClaw, including provider selection and session management. - Ensure existing provider functionalities remain intact while adding support for OpenClaw. Made-with: Cursor
1 parent 327c7b1 commit 9182a02

17 files changed

Lines changed: 803 additions & 67 deletions
Lines changed: 254 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,254 @@
1+
# Plan: Roll Out OpenClaw as an OK Code Provider
2+
3+
## Summary
4+
5+
Add **OpenClaw** to OK Code as a third provider runtime alongside `codex` and `claudeAgent`.
6+
7+
This should be implemented as a **provider integration**, not as a one-off model entry. OpenClaw would own model routing and execution, while OK Code continues to own thread UX, provider selection, health reporting, and session orchestration.
8+
9+
## Goals
10+
11+
- Let users select **OpenClaw** from the provider/model picker.
12+
- Support a practical MVP quickly without blocking on full provider parity.
13+
- Preserve OK Code's current provider architecture instead of adding ad-hoc special cases.
14+
- Keep the rollout safe by phasing higher-risk features after the basic session loop works.
15+
16+
## Non-goals (initial rollout)
17+
18+
- Full OpenClaw tool/event parity on day one.
19+
- Perfect rollback/history parity before an MVP exists.
20+
- Replacing existing Codex or Claude provider flows.
21+
- Supporting every OpenClaw capability in the first release.
22+
23+
## Recommended rollout shape
24+
25+
- **Phase 0:** architecture + contracts groundwork
26+
- **Phase 1:** UI + config plumbing
27+
- **Phase 2:** MVP OpenClaw adapter (usable provider)
28+
- **Phase 3:** richer session/history/approval parity
29+
- **Phase 4:** polish, observability, and hardening
30+
31+
---
32+
33+
## Phase 0 — Architecture and contract groundwork
34+
35+
### Objective
36+
37+
Define OpenClaw as a first-class provider in contracts and app state without yet making it fully executable.
38+
39+
### Checklist
40+
41+
- [ ] Add `openclaw` to `ProviderKind`.
42+
- [ ] Decide whether OpenClaw-specific options live under `providerOptions.openclaw` or a new dedicated config object.
43+
- [ ] Define initial OpenClaw provider start options, likely including:
44+
- [ ] gateway/base URL
45+
- [ ] auth token or password reference
46+
- [ ] default agent/session mode
47+
- [ ] optional model override
48+
- [ ] Add OpenClaw model option strategy:
49+
- [ ] start with static built-ins **or**
50+
- [ ] start with manual custom model slugs only **or**
51+
- [ ] fetch dynamic models later as a follow-up
52+
- [ ] Set a clear default for session model switching support (`in-session`, `restart-session`, or `unsupported`).
53+
- [ ] Decide MVP behavior for unsupported provider features:
54+
- [ ] rollback
55+
- [ ] thread snapshot reads
56+
- [ ] approval routing
57+
- [ ] structured user input
58+
59+
### Likely files
60+
61+
- `packages/contracts/src/orchestration.ts`
62+
- `packages/contracts/src/model.ts`
63+
- `packages/contracts/src/provider.ts`
64+
- `packages/contracts/src/server.ts`
65+
66+
### Exit criteria
67+
68+
- `openclaw` exists in contracts/types without breaking existing providers.
69+
- MVP capability decisions are documented and not left implicit.
70+
71+
---
72+
73+
## Phase 1 — UI and settings plumbing
74+
75+
### Objective
76+
77+
Make OpenClaw visible and selectable in the OK Code UI, even if execution is still stubbed or gated behind availability checks.
78+
79+
### Checklist
80+
81+
- [ ] Add OpenClaw to provider picker options.
82+
- [ ] Add an icon/label treatment for OpenClaw in the model picker.
83+
- [ ] Update provider-specific app settings and custom model handling.
84+
- [ ] Add settings UI for OpenClaw connection details.
85+
- [ ] Add provider install/configuration copy in settings.
86+
- [ ] Extend provider health banner/status display to recognize OpenClaw.
87+
- [ ] Ensure draft persistence/store logic can serialize OpenClaw provider selections.
88+
- [ ] Ensure thread/session display can show `providerName: "openclaw"` cleanly.
89+
90+
### Likely files
91+
92+
- `apps/web/src/session-logic.ts`
93+
- `apps/web/src/components/chat/ProviderModelPicker.tsx`
94+
- `apps/web/src/routes/_chat.settings.tsx`
95+
- `apps/web/src/appSettings.ts`
96+
- `apps/web/src/composerDraftStore.ts`
97+
- `apps/web/src/store.ts`
98+
99+
### Notes
100+
101+
For MVP, it is acceptable for the UI to show OpenClaw only when:
102+
- the provider is configured, or
103+
- a feature flag is enabled.
104+
105+
### Exit criteria
106+
107+
- Users can select OpenClaw in the UI.
108+
- App state and settings persist the choice correctly.
109+
- Existing Codex/Claude picker behavior remains unchanged.
110+
111+
---
112+
113+
## Phase 2 — MVP OpenClaw adapter
114+
115+
### Objective
116+
117+
Ship a usable OpenClaw-backed provider that supports the core thread loop:
118+
**start session → send turn → stream output → stop session**.
119+
120+
### Checklist
121+
122+
- [ ] Implement `OpenClawAdapter` using the existing `ProviderAdapter` contract.
123+
- [ ] Register the adapter in the provider registry.
124+
- [ ] Wire the adapter into server layers.
125+
- [ ] Map OK Code thread lifecycle to OpenClaw session lifecycle.
126+
- [ ] Implement `startSession`.
127+
- [ ] Implement `sendTurn`.
128+
- [ ] Implement `interruptTurn` if OpenClaw supports it cleanly; otherwise define MVP fallback behavior.
129+
- [ ] Implement `stopSession`.
130+
- [ ] Implement `listSessions`.
131+
- [ ] Stream assistant output back into OK Code's canonical provider event stream.
132+
- [ ] Normalize OpenClaw errors into OK Code provider errors.
133+
- [ ] Add provider health probing for OpenClaw reachability/authentication.
134+
- [ ] Gate the provider as unavailable when config or auth is missing.
135+
136+
### Likely files
137+
138+
- `apps/server/src/provider/Layers/OpenClawAdapter.ts`
139+
- `apps/server/src/provider/Services/OpenClawAdapter.ts`
140+
- `apps/server/src/provider/Layers/ProviderAdapterRegistry.ts`
141+
- `apps/server/src/serverLayers.ts`
142+
- `apps/server/src/provider/Layers/ProviderHealth.ts`
143+
144+
### MVP behavioral constraints
145+
146+
- [ ] One OpenClaw session per OK Code thread.
147+
- [ ] Basic text streaming required.
148+
- [ ] Rich tool/request parity optional.
149+
- [ ] Rollback may be unsupported initially if surfaced honestly.
150+
- [ ] Thread readback may be shallow or best-effort in MVP.
151+
152+
### Exit criteria
153+
154+
- A user can select OpenClaw and successfully complete a normal prompt/response cycle.
155+
- Streaming feels native enough for regular use.
156+
- Health/auth failures are visible and understandable.
157+
158+
---
159+
160+
## Phase 3 — Session, history, and approval parity
161+
162+
### Objective
163+
164+
Reduce the behavioral gap between OpenClaw and the native Codex/Claude integrations.
165+
166+
### Checklist
167+
168+
- [ ] Implement `readThread` with meaningful history reconstruction.
169+
- [ ] Implement `rollbackThread`, or explicitly model why rollback is unsupported.
170+
- [ ] Improve resume/reconnect behavior for long-lived OpenClaw sessions.
171+
- [ ] Decide how approval requests are surfaced:
172+
- [ ] OpenClaw-native approvals only
173+
- [ ] translated into OK Code approvals
174+
- [ ] hybrid with clear ownership
175+
- [ ] Support structured user-input prompts if OpenClaw exposes them.
176+
- [ ] Improve event translation for tools, progress states, and status updates.
177+
- [ ] Preserve provider refs/IDs where useful for resumability and debugging.
178+
179+
### Design questions to resolve
180+
181+
- [ ] Does OK Code own approvals, or does OpenClaw own approvals?
182+
- [ ] How should rollback behave if OpenClaw sessions are not trivially rewindable?
183+
- [ ] Should OpenClaw session state be persisted directly, indirectly, or only via transcript replay?
184+
185+
### Exit criteria
186+
187+
- OpenClaw threads behave predictably across refreshes, resumes, and longer conversations.
188+
- Missing parity is minimal and intentional rather than accidental.
189+
190+
---
191+
192+
## Phase 4 — Polish, dynamic models, and hardening
193+
194+
### Objective
195+
196+
Make OpenClaw feel like a polished built-in provider rather than a basic bridge.
197+
198+
### Checklist
199+
200+
- [ ] Add dynamic model discovery from OpenClaw if available.
201+
- [ ] Support richer provider-specific model options where meaningful.
202+
- [ ] Improve install/setup guidance in settings.
203+
- [ ] Add better telemetry/logging around OpenClaw session failures.
204+
- [ ] Add browser/manual test coverage for picker/settings flows.
205+
- [ ] Add adapter-focused unit tests and integration tests.
206+
- [ ] Add resilience for network interruptions and transient gateway failures.
207+
- [ ] Add clearer recovery messaging for auth/config/session mismatch errors.
208+
209+
### Exit criteria
210+
211+
- Setup is understandable.
212+
- Errors are debuggable.
213+
- OpenClaw feels like a normal provider choice inside OK Code.
214+
215+
---
216+
217+
## Cross-cutting risks
218+
219+
- OpenClaw session semantics may not map perfectly onto OK Code's provider assumptions.
220+
- Approval handling may become confusing if both systems try to own the same UX.
221+
- Rollback/history parity may require deeper transcript/state mapping than the MVP needs.
222+
- Provider model discovery may be dynamic in OpenClaw while OK Code currently prefers static provider model catalogs.
223+
224+
## Cross-cutting decisions to keep explicit
225+
226+
- [ ] Is OpenClaw primarily a **remote runtime** or a **thin bridge** in MVP?
227+
- [ ] Are OpenClaw models static, custom-only, or dynamically discovered in the first release?
228+
- [ ] Is rollback required for launch, best-effort, or explicitly unsupported?
229+
- [ ] Who owns approval UX in the integrated flow?
230+
231+
## Suggested order of implementation
232+
233+
1. Phase 0 contracts
234+
2. Phase 1 picker/settings plumbing
235+
3. Phase 2 MVP adapter + health checks
236+
4. Manual smoke testing
237+
5. Phase 3 parity work
238+
6. Phase 4 polish/hardening
239+
240+
## Validation checklist
241+
242+
- [ ] Typecheck passes across contracts, web, and server.
243+
- [ ] Existing Codex and Claude flows still work.
244+
- [ ] OpenClaw shows correct provider health in settings/chat.
245+
- [ ] New OpenClaw thread can start, stream, and stop successfully.
246+
- [ ] Misconfigured OpenClaw setup fails with a useful message.
247+
- [ ] Re-opening the app preserves provider selection and model choice.
248+
249+
## Done criteria
250+
251+
- OpenClaw is selectable as a provider in OK Code.
252+
- A normal thread can run end-to-end through OpenClaw.
253+
- Provider health and configuration are understandable.
254+
- Advanced parity gaps are documented and tracked rather than hidden.

.plans/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,3 +10,4 @@
1010
8. `08-precommit-format-and-lint.md`
1111
9. `09-event-state-test-expansion.md`
1212
10. `10-unify-process-session-abstraction.md`
13+
11. `11-openclaw-provider-rollout.md`

0 commit comments

Comments
 (0)