Runi Help
Email us Start trial

OpenClaw

A fresh install publishes nothing, and that is expected. One config line fixes it.

A fresh OpenClaw install publishes nothing to Runi, and that is expected rather than broken. Every other agent is started inside a checkout. OpenClaw is started inside a workspace, and the default workspace is not a repository, so there is nothing Runi can attribute a session to.

If OpenClaw is publishing nothing, you almost certainly need the first section below and nothing else.

The default workspace is not a repository#

Out of the box, OpenClaw's agent works in ~/.openclaw/workspace. That folder is not a Git checkout, so it has no repository identity, so nothing about a session there can be attributed to a repository your team tracks. Runi publishes nothing.

The doctor says this in as many words:

output
 warn  openclaw  workspace ~/.openclaw/workspace is not a Git repository —
                OpenClaw sessions there publish nothing. Point the agent at
                a checkout Runi tracks (agents.defaults.workspace in
                openclaw.json).

Point the agent at a checkout#

  1. Decide which repository the agent works in#

    It has to be one your workspace tracks. If it is not, add it first. See Repositories.

  2. Set the workspace in openclaw.json#

    For the default agent that is agents.defaults.workspace. For a named agent it is agents.entries.<id>.workspace.

    Note

    OpenClaw's default agent is called main, not default, and an operator can rename it again in agents.defaults.agentId. If you are editing agents.entries.main.workspace and nothing changes, you are probably editing the wrong half of the config. The defaults block is what the default agent reads.

  3. Confirm#

    terminal
    $ runi doctor
…
  ok   openclaw  workspace resolves to relay, which is tracked —
                OpenClaw sessions publish

    The doctor stays quiet about OpenClaw entirely if it is not installed. A machine that has never had it does not need a line about it.

What Runi installs#

The Runi plugin, copied into OpenClaw's extensions directory and enabled in openclaw.json. Unlike the other agents there is no MCP registration for OpenClaw. The briefing arrives through the plugin.

How the briefing arrives#

Through OpenClaw's before_prompt_build hook, which may return appendSystemContext. That is a real injection point, the analogue of Claude Code's SessionStart reply.

Careful

An operator can revoke it, and Runi cannot tell. Setting plugins.entries.runi.hooks.allowPromptInjection: false in openclaw.json makes OpenClaw drop the context the plugin returns. Sessions stay observed and stop being briefed, with nothing on our side able to detect the difference. If OpenClaw sessions publish but are never briefed, check that flag first.

What is recorded#

  • Your prompts, the files OpenClaw changes, the commands it runs and their test results.
  • Tool calls, classified from OpenClaw's built-in tool names and their arguments.

A tool added by another plugin is still recorded, with the files it touched, but is described generically. Runi has no vocabulary for a tool it has never met, and inventing one would put a confident wrong label in a teammate's brief.

What Runi will never register#

Not llm_input, not llm_output, and no other hook carrying the model's private reasoning. The one hook it registers that could in principle delay a tool call is synchronous and does no I/O, so it cannot.

Known limits#

  • Workspace-scoped rather than repository-scoped, as above. That is the whole first section of this page for a reason.
  • Prompt injection can be switched off per plugin by an operator, invisibly to Runi.
  • Tools from other plugins are recorded generically.
  • The briefing lands once per session, on the first turn.

Did this solve it?