openclaw-code-agent 4.1.0 → 4.1.2

package/README.md

@@ -6,8 +6,8 @@
 
 `openclaw-code-agent` is the OpenClaw plugin for running Claude Code and Codex as managed background coding sessions from chat. Launch work from Telegram, Discord, or any OpenClaw-supported channel, review the plan before execution, keep the job isolated in its own git worktree, and merge or open a PR without leaving the thread.
 
-- **Plan -> Review -> Execute**. `plan` is the default launch mode, with `ask`, `delegate`, and `approve` deciding how much plan approval autonomy the orchestrator gets.
-- **Optional worktree isolation**. New sessions default to `off`; opt into `ask`, `delegate`, `auto-merge`, or `auto-pr` when you want worktree-backed branch isolation and post-run branch handling.
+- **Plan -> Review -> Execute**. `plan` is the default launch mode, and plan approval defaults to `delegate` so the orchestrator reviews the full plan before approving or escalating to the user.
+- **Delegated worktree isolation**. New sessions default to `delegate`; opt into `ask`, `off`, `manual`, `auto-merge`, or `auto-pr` when you want a different branch follow-through policy.
 - **State-driven decision UX**. `ask` sends explicit action buttons for **Merge locally**, **Create PR**, **Decide later**, and **Dismiss**. The same action-token model now backs both Telegram and Discord interactive callbacks.
 - **Lifecycle-first cleanup**. Worktrees are treated as temporary task sandboxes. The plugin distinguishes `merged` from `released` so different-SHA branches whose content already landed on the base branch can still be cleaned safely.
 - **Full session lifecycle**. Suspend, resume, fork, interrupt, and recover sessions across restarts with persisted metadata and output.
@@ -28,14 +28,16 @@ Need the ACPX vs Codex vs code-agent breakdown? See [docs/ACP-COMPARISON.md](doc
 
 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.
 
-## New In 4.1.0
+## New In 4.1.2
 
-`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.
+`4.1.2` is a plan-approval reliability patch for the OpenClaw `2026.5.4` release line. It keeps the `>=2026.4.21` compatibility floor and the `4.1.1` build/test target, while tightening the user-facing approval path that gates implementation.
 
-- **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.
-- **Deterministic runtime state**. Completion and no-change paths now surface canonical approval/runtime state instead of asking operators to infer it from transcript text.
-- **Notification delivery reliability**. Direct notification timeouts, fallback failures, and completion-delivery diagnostics are handled explicitly so failed delivery is visible instead of silently hanging.
-- **Verified OpenClaw target**. Local build/test metadata targets stable OpenClaw `2026.4.29` while keeping the minimum compatibility floor at `>=2026.4.21`.
+- **Telegram plan approval buttons restored**. Plan prompts in Telegram use the shared direct-message presentation path and carry the canonical **Approve**, **Revise**, and **Reject** actions.
+- **Plain-text fallback is explicit**. While a plan is awaiting review, replying `Approve`, `Revise`, or `Reject` triggers the same approval, revision, or rejection path as the buttons.
+- **Stale prompts are suppressed**. Rejected or killed plan sessions no longer resurface an obsolete Plan v2 prompt as if it were still actionable.
+- **Verified release evidence**. A plan-gated `rust-hello-world` run, `rust-hello-world-minor-change-2` (`FzPCkqjh`), completed as `approved_then_implemented` after explicit approval; a later run (`VmUBWOH2`) delivered a clean plan prompt without the old stale Plan v2-after-reject behavior.
+
+The `4.1.1` OpenClaw `2026.5.4` compatibility work remains current: managed TaskFlow mirroring is opportunistic, deterministic runtime state is exposed in wakes, direct notification failures are surfaced, and local build/test metadata still targets stable OpenClaw `2026.5.4`.
 
 ## From Prompt To Merged Branch
 
@@ -119,11 +121,14 @@ Install and enable the plugin:
 openclaw plugins install openclaw-code-agent
 openclaw plugins enable openclaw-code-agent
 openclaw gateway restart
+openclaw plugins inspect openclaw-code-agent --runtime --json
 ```
 
 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.
 
-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.
+This release targets the OpenClaw `v2026.4.21` external plugin contract and is verified against the stable `v2026.5.4` 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, command activation surface, tool contracts, and onboarding metadata OpenClaw uses during plugin-config setup. Keep those metadata surfaces in sync when bumping the plugin release baseline.
+
+After install or update, inspect the runtime plugin view after the gateway restart. The runtime inspection should show the chat commands, service, and `agent_*` / `goal_*` tools without diagnostics. If `tools.effective` or `tools.invoke` cannot see `agent_launch` or `agent_sessions`, the installed plugin is stale or the gateway has not restarted onto the updated manifest and bundle.
 
 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.
 
@@ -131,11 +136,11 @@ The current manifest descriptors stay intentionally narrow: activation advertise
 
 In OpenClaw's Manual setup flow, the plugin should only ask for three first-run decisions:
 
-- `defaultWorkdir`: the repo or workspace path you expect to launch from most often
+- `defaultWorkdir`: the git repo path you expect to launch from most often
 - `defaultHarness`: whether your default harness is `claude-code` or `codex`
 - `fallbackChannel`: an optional but recommended fully routable notification target for async updates
 
-Everything else stays advanced/manual. In particular, `agentChannels`, per-harness model policy, permission defaults, and worktree policy are intentionally deferred until after the first successful launch.
+Everything else stays advanced/manual. In particular, `agentChannels`, per-harness model policy, permission defaults, and worktree policy are intentionally deferred until after the first successful launch, even though plan approval and worktree follow-through now default to delegated behavior. If your first launch must run outside a git repo, expand Advanced during setup or edit config afterwards and set `defaultWorktreeStrategy` to `off`.
 
 Add a minimal config block under `plugins.entries["openclaw-code-agent"]` in `~/.openclaw/openclaw.json`:
 
@@ -170,8 +175,10 @@ Add a minimal config block under `plugins.entries["openclaw-code-agent"]` in `~/
 You can leave the advanced settings at their defaults for the first run. The plugin defaults to:
 
 - `permissionMode: "plan"`
-- `planApproval: "ask"`
-- `defaultWorktreeStrategy: "off"`
+- `planApproval: "delegate"`
+- `defaultWorktreeStrategy: "delegate"`
+
+Because delegated worktree follow-through is now the default, the first-run `defaultWorkdir` should normally point at a git repository. Non-git workdirs are still supported by setting `defaultWorktreeStrategy: "off"` globally or by launching with `worktree_strategy: "off"`.
 
 If you run Codex sessions, keep Codex on the ChatGPT auth path:
 
@@ -209,6 +216,14 @@ Prefer fully routable channel strings such as `telegram|123456789` or `telegram|
 
 ### Upgrade Notes
 
+For OpenClaw `2026.5.4` readiness:
+
+- Build and SDK metadata now target OpenClaw `2026.5.4`; the peer floor remains `>=2026.4.21` for existing compatible installs.
+- If your OpenClaw config uses an exclusive `plugins.allow` list, include `openclaw-code-agent` or the plugin's `agent_*` / `goal_*` tools will not load even if `tools.allow` names them.
+- Harness model policy should live under `harnesses.codex.*` and `harnesses["claude-code"].*`. Legacy `defaultModel`, `model`, `reasoningEffort`, and global `allowedModels` are compatibility-only. Configured `reasoningEffort` supports `low`, `medium`, `high`, `xhigh`, and `max`.
+- Codex and Claude Code restrictions are harness-scoped. Codex defaults to `gpt-5.5` with `gpt-5.5` / `gpt-5.5-pro` allowed; Claude Code defaults to `anthropic/claude-sonnet-4-7` with `sonnet` / `opus` matching.
+- `tools.deny` does not disable OpenClaw's `apply_patch` tool by itself. Use OpenClaw's `tools.exec.applyPatch.*` settings when you need patch-tool policy.
+
 For `4.1.0`:
 
 - 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.
@@ -219,7 +234,7 @@ For `3.2.0`:
 
 If you are upgrading from `3.1.0`, the important behavioral changes are:
 
-- `defaultWorktreeStrategy` is back to `off`, so worktree isolation remains opt-in unless you configure it explicitly.
+- `defaultWorktreeStrategy` now defaults to `delegate`, so new sessions use worktree isolation and orchestrator-led follow-through unless you configure or launch with a different strategy.
 - `auto-merge` now attempts one autonomous conflict resolution before escalating.
 - Completion wakes and no-change outcomes are deterministic and carry explicit approval/execution state instead of relying on transcript inference.
 - Worktree cleanup is lifecycle-first and can now classify already-landed branches as `released`, which makes `preview_safe` and `clean_safe` more trustworthy after rebase, squash, or cherry-pick flows.