openclaw-code-agent 4.0.0 → 4.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +19 -10
- package/dist/index.js +136 -136
- package/openclaw.plugin.json +2 -1
- package/package.json +8 -6
- package/skills/code-agent-orchestration/SKILL.md +2 -0
package/README.md
CHANGED
|
@@ -28,15 +28,14 @@ Need the ACPX vs Codex vs code-agent breakdown? See [docs/ACP-COMPARISON.md](doc
|
|
|
28
28
|
|
|
29
29
|
The shared substrate is often the local `codex` command and Codex App Server, but the responsibilities are different. This plugin is not an ACP server and it does not depend on OpenClaw's bundled Codex provider to expose its own `codex` harness.
|
|
30
30
|
|
|
31
|
-
## New In 4.
|
|
31
|
+
## New In 4.1.0
|
|
32
32
|
|
|
33
|
-
`4.
|
|
33
|
+
`4.1.0` is the managed-lifecycle and notification reliability release. It keeps the `4.0.0` messaging-contract cleanup intact, preserves the `>=2026.4.21` compatibility floor, and adds the release-line fixes that make completion state and direct notification delivery deterministic.
|
|
34
34
|
|
|
35
|
-
- **
|
|
36
|
-
- **
|
|
37
|
-
- **
|
|
38
|
-
- **
|
|
39
|
-
- **Model refresh**. Built-in defaults now recommend `anthropic/claude-sonnet-4-7` for Claude Code and `gpt-5.5` for Codex, with `gpt-5.5-pro` also included in the built-in Codex allowlist.
|
|
35
|
+
- **Managed TaskFlow lifecycle**. When the current OpenClaw runtime exposes managed TaskFlow APIs, code-agent sessions now create, update, wait, and finalize a gateway-owned flow record; older runtimes fall back cleanly without changing session behavior.
|
|
36
|
+
- **Deterministic runtime state**. Completion and no-change paths now surface canonical approval/runtime state instead of asking operators to infer it from transcript text.
|
|
37
|
+
- **Notification delivery reliability**. Direct notification timeouts, fallback failures, and completion-delivery diagnostics are handled explicitly so failed delivery is visible instead of silently hanging.
|
|
38
|
+
- **Verified OpenClaw target**. Local build/test metadata targets stable OpenClaw `2026.4.29` while keeping the minimum compatibility floor at `>=2026.4.21`.
|
|
40
39
|
|
|
41
40
|
## From Prompt To Merged Branch
|
|
42
41
|
|
|
@@ -122,9 +121,11 @@ openclaw plugins enable openclaw-code-agent
|
|
|
122
121
|
openclaw gateway restart
|
|
123
122
|
```
|
|
124
123
|
|
|
125
|
-
|
|
124
|
+
Restart or reload the gateway only as part of your normal install/upgrade flow; it is not needed for editing docs or preparing a release branch.
|
|
126
125
|
|
|
127
|
-
|
|
126
|
+
This release targets the OpenClaw `v2026.4.21` external plugin contract and is verified against the stable `v2026.4.29` build/test target. `package.json` carries the plugin API compatibility and build metadata used by modern OpenClaw / ClawHub installs, and `openclaw.plugin.json` advertises the plugin-owned startup and command activation surface plus the onboarding metadata OpenClaw uses during plugin-config setup. Keep those metadata surfaces in sync when bumping the plugin release baseline.
|
|
127
|
+
|
|
128
|
+
The current manifest descriptors stay intentionally narrow: activation advertises startup loading plus only the chat commands this plugin owns, and setup stays minimal with `requiresRuntime: false`. First-run onboarding is driven by the manifest config schema and `uiHints`, not by provider/backend setup descriptors.
|
|
128
129
|
|
|
129
130
|
### First-Run Onboarding
|
|
130
131
|
|
|
@@ -206,7 +207,15 @@ For multi-workspace or multi-bot setups, configure `agentChannels`. The full rou
|
|
|
206
207
|
|
|
207
208
|
Prefer fully routable channel strings such as `telegram|123456789` or `telegram|my-bot|123456789`. A bare provider like `telegram` is only a weak fallback; the plugin now repairs topic routing from `originSessionKey` when possible, but explicit channels are still the safer default.
|
|
208
209
|
|
|
209
|
-
### Upgrade
|
|
210
|
+
### Upgrade Notes
|
|
211
|
+
|
|
212
|
+
For `4.1.0`:
|
|
213
|
+
|
|
214
|
+
- Managed TaskFlow integration is opportunistic. It uses OpenClaw's current managed-flow runtime when available and degrades to the existing session-only behavior when that surface is absent.
|
|
215
|
+
- Direct notification failures are now surfaced more explicitly. Treat a missing button delivery as a delivery/routing problem, not as evidence that the underlying plan or worktree state changed.
|
|
216
|
+
- Runtime and approval state fields in wakes are authoritative. Prefer them over transcript fragments when deciding whether execution was approved, bypassed, completed, or still waiting.
|
|
217
|
+
|
|
218
|
+
For `3.2.0`:
|
|
210
219
|
|
|
211
220
|
If you are upgrading from `3.1.0`, the important behavioral changes are:
|
|
212
221
|
|