About a week ago, I tried agent coding through OpenClaw but paused it after some initial tests. It seemed to work, but I wasn’t convinced there was enough benefit. Over the past few days, though, my mindset shifted—I decided to trust AI a bit more. Also, given the timing, I figured I should try everything that’s realistically possible. My growing familiarity with Claude Code and improved understanding of how OpenClaw operates also played a role.
This time, I approached it with the goal of understanding the mechanics. I asked questions to my OpenClaw agent, N.I.C.K., as well as to Gemini, and sketched out several possible approaches:
Method A: OpenClaw runs Claude Code and issues task instructions — personas are defined within Claude Code
Method B: OpenClaw directly develops using shell/file tools — OpenClaw switches personas during the work
Method C: OpenClaw main agent delegates by role to OpenClaw sub-agents — personas are assigned to sub-agents
Method D: OpenClaw main agent delegates to sub-agents, which then run Claude Code — personas defined in Claude Code
There were a couple of reasons I evaluated these combinations.
First, when OpenClaw runs subprocesses, it sometimes appears to miss termination signals, and I wasn’t fully confident about its control model there. In contrast, sub-agent execution seemed relatively well managed. Second, Claude Code already embeds a significant amount of development-specific prior knowledge, making it much easier to issue development tasks. If OpenClaw were to handle development directly, I would have to compensate for that missing prior knowledge myself.
Method D was discarded almost immediately at the thought-experiment stage. Subcontracting the subcontractor’s subcontractor is just too many layers deep. It would waste tokens and looked highly likely to recreate the classic “telephone game” problem in real-world organizations.
I briefly considered Methods B and C but dropped them as well. No matter how well I train an OpenClaw agent, it’s hard to beat a purpose-built tool like Claude Code that’s already highly optimized for development tasks.
That left me reasonably confident that Method A was the right direction. The conclusion was to focus on better subprocess management while letting Claude Code do what it does best.
There were some tangible gains. I developed a better understanding of how OpenClaw handles subprocesses:
- It can run background jobs
- It can run foreground jobs attached to a PTY
- It can launch a foreground job with a PTY and later push it to the background via the
yieldMecommand, returning the main session to idle
In the latter two cases, process completion signal handling also appeared to work reliably.
I also discovered that subprocesses have a timeout option that prevents long-running execution, with a default of 10 minutes. I learned this the hard way—after watching several processes mysteriously die about 10 minutes after starting.
Another useful finding: Claude Code has an equivalent to Codex’s -yolo option. One is the rather intimidating --dangerously-skip-permissions, and the other is --allowedTools "Read,Edit,Bash", which doesn’t grant full permissions but is sufficient for most practical scenarios.
After wrestling with this setup for a few hours, something clicked. Running things this way causes Claude Code to lose session continuity. The specs remain, so it might not be fatal, but losing shared context between personas (planner, developer, etc.) definitely consumes more tokens. Even repeated calls to the same persona would suffer from context fragmentation.
After thinking for a moment, I asked N.I.C.K.:
> If I keep a terminal session open, can you access it interactively? Or maybe through a tmux session?
The response:
Good idea! Both are possible. I recommend tmux.Advantages:* Session persistence (context preserved)* Even if I terminate the wrapper, Claude Code stays alive* Logs can be inspected directly in tmuxSo I had it install tmux and proceeded to test in that direction. Shortly after, N.I.C.K. showed me the familiar Claude Code console screen. After issuing a few commands, I confirmed that the session was preserved and instructions were flowing correctly.
There was still one issue: N.I.C.K. cannot reliably detect when Claude Code has finished executing an injected prompt. At this point, the options are polling or manually checking.
After further discussion with Gemini and N.I.C.K., several ideas emerged—file-based flags, sending direct messages into the session via the OpenClaw CLI, and so on. The most reliable conclusion was to explicitly instruct Claude Code:
> When you complete this task, report completion in the following way.
It’s reliable—but admittedly a bit cumbersome.
For today, I’ll stop here. Among the approaches I tested, the tmux-based method looks the most promising so far. Tomorrow, I’ll dig deeper in that direction.
Kirin's Technology Essay 