After I connected OpenClaw to Discord, I ran into one problem that became particularly annoying: the agent had clearly done the work, but the final message never made it back to Discord.

A bad answer is easier to debug. I can inspect the prompt, the context, or the way the model understood the task. A missing reply sends me down a much longer list: Gateway, session, queue, Discord plugin, provider, network, and whatever changed in the last update.

Those extra layers are also a big part of what makes OpenClaw useful. It brought persistent agents, channels, memory, skills, plugins, MCP, routing, cron and background work into one self-hosted runtime early on.[1][2] I still use it when I actually want an agent that stays online and is reachable from several places.

My engineering work gradually moved somewhere else. Most days I was dealing with implementation inside repositories, parallel changes, reviews, debugging and verification. I kept opening Codex for those jobs, and after a while it simply became the main tool.

OpenClaw and Codex organise agent work around different centres

I still think OpenClaw is a pretty good fit for a persistent agent

OpenClaw is built around the idea of a multi-channel gateway for AI agents. WhatsApp, Telegram, Discord, iMessage and other surfaces can all feed into the same Gateway, with sessions, routing and channel connections handled there.[1]

That matched what I wanted when I first set it up. The agent stayed on my own machine, I could reach it from Discord, and I could come back hours later without treating everything as a fresh coding session. Memory, workspace state and channel continuity all lived in the same runtime.

The multi-agent side was already fairly complete too. Agents could have their own workspaces, agentDirs, authentication profiles, session stores, skills and models, while the Gateway routed traffic by channel, account or peer.[2] It also had /steer, subagent steering, MCP and plugin management.[3][4]

This is why I have never found feature-by-feature comparisons very useful here. A lot of the same labels exist on both sides. What changes the experience is what you spend your day managing.

Most of my day eventually became a Git-state problem

Once the Codex app was on macOS, projects, threads, worktrees, diffs, review, skills and automations all sat in the same place, and several agents could work in parallel.[5]

I started leaning on worktrees very quickly.

OpenClaw gives persistent agents sensible boundaries. Workspaces, sessions, credentials and skills can stay separate, and the Gateway decides where a Discord or Telegram message should go. That makes a lot of sense for a personal assistant.

Inside a repository, I kept worrying about something else: which working state was each agent touching?

Could two agents step on the same uncommitted changes? Which diff am I reviewing? Which branch of work is actually ready to go back into main?

Git worktrees made that much easier to reason about. One agent could work in one worktree while another handled something else, and I could review the diffs separately before deciding what to keep.[5]

After a while, that just matched my real work better. I was spending far more time managing code and changes than managing agent identity.

Being able to correct a long job halfway through makes a big difference

GPT-5.3-Codex came with mid-turn steering, so I could add guidance while the agent was still working without throwing away the existing context.[6]

That sounds small until a job has been running for a while.

The agent might miss a file. It might head down an implementation path I do not want. Sometimes I change the requirement myself halfway through. I usually do not want to restart everything. I just want to say, “Don’t go that way. Check these two files first,” and let it carry on.

OpenClaw has /steer, /subagents steer and queue controls too.[3] I still found myself steering more often in Codex because the thread, worktree, terminal, diff, review and approvals were all right there. If something looked wrong, I could pull it back without jumping into another control surface.

OpenAI’s Harness Engineering article helped put words around something I was already noticing: the repository, tests, CI, documentation, observability, review and feedback loops are all part of whether an agent can do engineering work properly.[7]

That is pretty close to how I look at agent tools now. I still care about the model, obviously, but I also look at where context comes from, what the tools can touch, how work is isolated, how I inspect a failure, and how I verify the result.

A lot of the March Codex updates were filling in those gaps: Local and Worktree thread handoff, GitHub and pull-request improvements, integrated terminal access, Automations, better Diff / Review navigation, past-thread search, and Plugins bundling skills, app integrations and MCP configuration.[8]

I did not switch because of one release note. I just noticed, over time, that I was crossing fewer boundaries while doing the same engineering job.

When Discord goes quiet, the debugging is mine

I had OpenClaw runs where the agent had clearly finished, but the final Discord message never appeared.

At that point the path looks something like this:

Discord
Gateway
Session
Queue
Provider
Agent
Reply

Then you have plugins, networking, configuration, versions, authentication and timeouts sitting around it as well. Any one of them might be where things went wrong.

Possible failure surfaces in the OpenClaw reply delivery path

OpenClaw also moves quickly. In my own setup, an upgrade often meant checking the channel, Gateway, provider, configuration and plugins again before I trusted the whole path.

That is not unusual for fast-moving open-source software. It is just work, and I am the one doing it.

There were public reports of very similar problems. One issue described Discord replies silently disappearing after the first outbound message on 2026.5.4. Another reported Gateway event-loop degradation, Discord heartbeat timeouts and a local status call taking about 50 seconds.[9][10]

I would not use those two issues to say OpenClaw is generally unreliable. They were useful to me because they showed that other people had run into the same kind of problem.

If I need a persistent agent across several channels, I am happy to carry some of that maintenance. The Gateway is doing something I actually want.

If I am just trying to change code, inspect a diff, run tests and debug a UI, I start wondering why I am operating another layer at all.

Codex feels closer to the way I actually debug

As the Codex app grew, more of the things I already use during debugging moved into the same workspace: an in-app browser, Computer Use, Chats, a deeper pull-request flow, an artifact viewer, multiple terminals and SSH remote connections.[11]

The browser and terminal mattered most to me.

Codex could already read the integrated terminal. Later it could also operate the in-app browser against local development servers and file-backed pages, click through the UI, reproduce a visual bug and check whether a local fix actually worked. Automatic approval reviews arrived in the same stretch.[12]

So a frontend bug could stay inside one loop:

Edit code
↓
Run
↓
Read terminal
↓
Inspect UI
↓
Reproduce
↓
Fix
↓
Verify
↓
Review / Approve

Codex engineering verification loop

OpenClaw can build a similar flow with browser access, shell tools and plugins.[3][4] What I notice in practice is the amount of setup and switching.

With Codex, the terminal, browser, worktree, diff and review are already where I am working. I do not have to think about wiring another Gateway layer into the job first.

This is one of the questions I ask when I try an agent tool now: after it says the task is done, how much work is still sitting on my side?

If I still need to check the terminal, open the browser, compare the diff and then feed everything back into another agent surface, it does not really feel finished yet.

I do not rely on OpenClaw as much just to check work away from my desk

Remote access was one of the big reasons I liked OpenClaw in the first place. I could leave the machine and still reach the agent from Discord.

Later, Codex could also reconnect through the ChatGPT mobile app to a Mac running the Codex app, with the same projects, files, credentials, plugins, skills and configuration available from the host.[13]

OpenClaw is still much more flexible if I want Discord, Telegram, WhatsApp and a persistent agent living across channels.

But for engineering work, I no longer need a separate Gateway just because I want to check progress from outside, add a note or approve something.

The plugin story feels similar. OpenClaw already had its own plugin, skill and MCP surfaces.[3][4] Codex’s plugin model bundled skills, app integrations and MCP configuration and could scope them to a user or a repository.[8]

For repo work, I prefer that. I can think about the capabilities alongside the project. For long-running personal workflows that need to span channels, I still go back to OpenClaw.

I started noticing quite a few people in community threads asking whether the extra layer was really worth it

A V2EX thread asked, pretty directly, what OpenClaw added over remotely operating Claude or Codex. The concerns sounded familiar: plenty of coding work was already straightforward in Claude Code, while OpenClaw meant more setup around login, skills, browser automation and reliability.[14]

Then there was the money side.

Anthropic told customers that Claude subscription limits would no longer cover third-party harnesses such as OpenClaw. Continuing to use Claude through them meant pay-as-you-go usage or API billing.[15]

At the same time, Claude Code itself was getting more comfortable with longer jobs. Anthropic’s usage research showed the longest interactive turns stretching past 45 minutes, and on 6 May the company doubled Claude Code’s five-hour rate limits for Pro, Max, Team and seat-based Enterprise users.[16][17]

OpenClaw’s public web traffic also dropped sharply in April. A Feifan Research report estimated visits at about 14.2 million, down 50.67% month on month, with unique visitors down 46.98%.[18] I would treat that as a sign that public attention had cooled, not as proof that half the users had left.

Codex was moving the other way on official usage figures: OpenAI said more than 3 million developers were using Codex weekly in early April, rising above 4 million two weeks later.[19]

I do not think those numbers prove that everyone moved from OpenClaw to Codex. My read is much simpler: coding-heavy users had more reasons to stay inside first-party coding harnesses, while persistent personal agents still solved a different job.

This is roughly how I split the work now

WorkloadMy first choiceWhy
Persistent multi-channel assistantOpenClawGateway, channels and sessions are part of the job
Self-hosted personal automationOpenClawI want a long-running runtime under my control
Repository implementation / refactoringCodexWorktree, diff and review are already in the same workspace
Parallel code changesCodexWorking-state isolation matters more than agent identity
Frontend debugging / verificationCodexThe terminal, browser and review loop is shorter
Checking engineering progress away from the computerCodex or OpenClawIt depends on whether I want project continuity or channel continuity

I do not expect that split to stay fixed forever.

If most of my work moves back towards cross-channel personal automation, OpenClaw will probably take more of the load again.

Right now, though, most of what I deal with every day is repository state, review, debugging and verification. So Codex is the one I end up opening first.

References

  1. OpenClaw, v2026.3.31, OpenClaw documentation: What is OpenClaw?, 25 March 2026.
  2. OpenClaw, v2026.3.31, Multi-Agent Routing.
  3. OpenClaw, v2026.5.7, Slash commands, including /steer, subagent steering, /mcp, and /plugins.
  4. OpenClaw, v2026.5.7, Plugins.
  5. OpenAI, Introducing the Codex app, 2 February 2026.
  6. OpenAI, Introducing GPT-5.3-Codex, 5 February 2026.
  7. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
  8. OpenAI, ChatGPT & Codex changelog, March 2026 entries, especially 3, 11, 12, 19, 24 and 25 March.
  9. OpenClaw GitHub issue #78104, Discord outbound silent-drop regression report, opened 5 May 2026.
  10. OpenClaw GitHub issue #77995, Gateway event-loop / Discord heartbeat regression report, opened 5 May 2026.
  11. OpenAI, Codex for (almost) everything and Codex changelog, 16 April 2026.
  12. OpenAI, ChatGPT & Codex changelog, 23 April 2026: Browser Use and Automatic Approval Reviews.
  13. OpenAI, ChatGPT & Codex changelog, 14 May 2026: Work with Codex from anywhere.
  14. V2EX, OpenClaw 跟我遠程操作 Claude/Codex 的區別在哪兒？, 5 March 2026. Community anecdote, used only as evidence that this question was already being discussed.
  15. TechCrunch, Anthropic says Claude Code subscribers will need to pay extra for OpenClaw usage, 4 April 2026, reporting Anthropic’s customer notice and public explanation.
  16. Anthropic, Measuring AI agent autonomy in practice, 18 February 2026.
  17. Anthropic, Higher usage limits for Claude and a compute deal with SpaceX, 6 May 2026.
  18. Feifan Research via Sina Finance, OpenClaw April 2026 web-traffic report, 11 May 2026. Web-traffic data, not an active-user measure.
  19. OpenAI, Scaling Codex to enterprises worldwide, 21 April 2026.