Refine and Rebase OpenClaw Adapter Integration
Public
Refine and Rebase OpenClaw Adapter Integration
Agent
Codex
Model
GPT-5.4
Shared
Mar 17, 1:29 PM
Messages700
Downloads60
The worktree naming pattern in this repo uses feat/<adapter>-adapter for new adapters, so I’m checking whether feat/openclaw-adapter already exists before creating it with the repo script.
I have enough repo structure now. The next gap is just the exact OpenClaw event taxonomy so I can write precise failing tests instead of a vague “JSONL parser” placeholder. I’m summarizing the real session file into line types and fields before I start editing.
Creating the OpenClaw share-to-traces skill file is part of this change, so I’m pulling in the skill-creator skill before I write that asset. The adapter work stays in packages/shared + cli; I’m not touching frontend/logo wiring yet unless typechecks force it.
I’ve finished the read phase. The edit pass is going to add a minimal OpenClawAdapter stub plus OpenClaw fixture-based tests in the CLI, wire the new agent ID into packages/shared and CLI types/registry/config, and add an installable share-to-traces SKILL asset + setup manifest for OpenClaw.
The first patch attempt missed a couple of exact anchors in existing test files, so nothing was committed. I’m redoing this in smaller, safer chunks: first the new files and type/registry wiring, then the contract/setup test updates, then I’ll run the failing test set before implementing the parser.
The stub and the OpenClaw-specific fixture/tests are in place. I’m wiring those into the shared contract suites and setup/install tests now, then I’ll run the targeted OpenClaw test set so we get the intentional red state before I replace the stub with real parsing.
The OpenClaw surface is wired into the test suite now. I’m running only the OpenClaw-named tests first so we get a clean failing baseline from the stub instead of a wall of unrelated output.
The pattern filter skipped the new file unexpectedly, so I’m switching to explicit file execution. That’s enough to confirm the expected red state from the stub without relying on Bun’s name filter.
I’ve got the setup/install side green. Now I’m running the new OpenClaw adapter tests with explicit ./... paths so Bun actually picks them up; this should give us the expected failures from the stubbed adapter.
I’ve confirmed there isn’t already an openclaw worktree or branch. Next step is running the repo helper to create feat/openclaw-adapter from main, which will also symlink env files and install dependencies in the new checkout.
The patch tool wrote into the main checkout instead of the feat-openclaw-adapter worktree because it’s anchored to the default repo root here. I’m copying the exact changes into the worktree paths now and then cleaning the accidental main-tree edits before I continue.
I’ve isolated the accidental writes: they’re only in the OpenClaw-related files plus a few tracked files I intentionally edited, while the existing dirty cli/src/core/* files are unrelated and staying untouched. I’m syncing just the OpenClaw changes into the worktree and leaving the unrelated main-tree edits alone.
The helper script has created the branch and worktree and is now finishing bun install inside the new checkout. I’m waiting for that to complete, then I’ll verify the branch and symlinked env files.
The changes are now in the correct worktree. I’m rerunning the OpenClaw-focused adapter tests there; this is the real failing baseline we wanted before replacing the stub.
I’m replacing the stub with a real JSONL adapter now. The implementation will use sessions.json for discovery, parse OpenClaw message/toolResult blocks into Traces events, derive cwd hints from session/tool arguments, and support cold reads plus file-tail subscriptions.
The unit-level parser tests are green. I’m widening the verification now to the shared contract/watcher suites and the setup/install tests, but still scoped to the new OpenClaw surface so I can catch integration gaps without burning time on the entire CLI matrix yet.
The OpenClaw integration path is green. I’m doing one broader pass across the full modified test files now so the registry/setup/contract changes don’t accidentally break another adapter while I’ve got the area open.
OpenClaw support is implemented in the feat-openclaw-adapter worktree.
I added the shared/CLI agent ID wiring in agent.ts and types.ts, registered the adapter in index.ts, and implemented the adapter itself in v1.ts. It now discovers sessions from ~/.openclaw/agents/main/sessions/sessions.json, parses OpenClaw JSONL messages into Traces events, derives cwd hints from session/tool paths, supports cold reads without persisted sourcePath, and subscribes to appended events.
I followed the test-first flow you asked for: added the OpenClaw tests in v1.test.ts, confirmed they failed against the stub, then finished the implementation. I also added the installable skill asset at SKILL.md and wired traces setup support in setup-assets.ts.
Verification: bun test ./cli/src/adapters/index.test.ts ./cli/src/adapters/openclaw/v1.test.ts ./cli/src/commands/setup.test.ts ./cli/test/core/adapters.test.ts ./cli/test/core/adapters-watcher.test.ts passed with 321 pass, 0 fail.
I did not wire the logo/frontend yet. I also left the accidental duplicate edits in the main checkout alone rather than doing a destructive cleanup without approval; the intended work is present in the worktree.
I’m checking the main checkout and the feat-openclaw-adapter worktree side by side so I can tell you exactly which files have the duplicate OpenClaw edits versus which dirty files were already unrelated.
I’ve got the overlap from git status. I’m doing a byte-for-byte check on the shared OpenClaw files now so I can confirm they’re truly duplicated, not just modified in both places for different reasons.
One file is not a perfect duplicate: cli/src/adapters/openclaw/v1.ts. I’m checking that diff specifically so I can tell you whether the main checkout still has the earlier stub or some partial version.
The duplicate OpenClaw-related edits in the main checkout are these files, and they are byte-for-byte identical to the copies in the feat-openclaw-adapter worktree:
One overlapping file is not identical:
That one is the main reason I didn’t casually clean up the main checkout: the main checkout still has the earlier stub/partial version, while the worktree has the full implementation.
Unrelated dirty files in the main checkout that are not part of the OpenClaw duplication are:
If you want, I can clean just the duplicate OpenClaw edits out of the main checkout and leave those unrelated cli/src/core/* changes alone.
I’m going to separate the main checkout’s state into two buckets: the accidental OpenClaw duplication to remove from main, and the unrelated cli/src/core/* edits to preserve on a new branch/worktree fix-git-not-saving. Then I’ll verify both checkouts are clean where they should be.
I’m preserving the three unrelated cli/src/core/* edits first so I can clear the main checkout without losing them. Then I’ll create the fix-git-not-saving branch/worktree, apply those preserved changes there, and finally remove the accidental OpenClaw edits from main.
Using the git-worktree skill here because you want the unrelated main-checkout changes moved onto a separate branch without mixing them into the OpenClaw work. I’m checking the current repo state and then I’ll create fix-git-not-saving, move the stashed cli/src/core/* edits there, and clean the accidental OpenClaw files out of main.
I’ve confirmed the main checkout only has the accidental OpenClaw carryover now, and the unrelated cli/src/core/* edits are safely in a stash entry named fix-git-not-saving carryover. Next I’m splitting that stash into a dedicated fix-git-not-saving worktree/branch, then I’ll restore main by removing the OpenClaw files and reverting the OpenClaw-related edits there.
The new fix-git-not-saving worktree is being created now with the usual env symlinks and dependency install. Once that finishes I’ll apply the stashed core changes there and then clean the main checkout.
Using the git-worktree skill for this since you asked for it explicitly. I’m opening the skill instructions and checking the repo’s current branch state before creating the openclaw worktree.
I’ve moved the unrelated cli/src/core/* edits onto the new fix-git-not-saving worktree. I’m restoring the main checkout next by reverting the OpenClaw-related tracked files there and deleting the untracked OpenClaw adapter, fixture, and installable skill files that were copied into main by mistake.
The untracked OpenClaw files are gone from main. The tracked-file restore hit a sandbox lock on .git/index.lock, so I’m rerunning that restore with elevated repo access and then I’ll verify both worktrees are in the expected state.
The split is in the right shape now: main is clean, fix-git-not-saving contains only the three unrelated cli/src/core/* edits, and feat-openclaw-adapter still holds the OpenClaw work. I’m marking verification complete and then I’ll summarize the exact result, including the stash I left in place as a backup.
main is clean again. I removed the accidental OpenClaw carryover there by deleting the untracked OpenClaw files and restoring the OpenClaw-related tracked edits.
The unrelated changes are now on branch fix-git-not-saving in a new worktree at /Users/tarunsachdeva/code/traces-worktrees/fix-git-not-saving. That worktree currently has:
The OpenClaw work is still intact in /Users/tarunsachdeva/code/traces-worktrees/feat-openclaw-adapter. I left stash@{0} (fix-git-not-saving carryover) in place as a backup; I can drop it if you want.
I’m switching back to the OpenClaw worktree and inspecting the local .traces databases to see what the current OpenClaw conversation is producing. I’ll map that data against the adapter shape so we can tighten the implementation from real transcripts instead of guessing.