Decisions

Why lnk-openclaw runs OpenClaw the way it does. Link's own decisions about harnesses are on its Agents Decisions page.

Why carry its state over ASP?

OpenClaw keeps its own sessions behind its gateway, and its hub replays them through openclaw acp's own list and load. A switch takes them out whole; none goes in, as its gateway takes no session from outside its own runs, and the switch says so rather than injecting history.

Where is OpenClaw's workspace?

In its home (~/Link/Agents/main/Harnesses/openclaw/.openclaw/workspace), with its personality and memory, and ~/Link/Agents/main/Home as the shared folder. Hermes works in Home.

How does OpenClaw use a local model?

Only through Ollama, registered with its address and Ollama's own API, and a context window of 32,768 tokens on both sides: OpenClaw's budget and Ollama's num_ctx. Ollama's default window, a few thousand tokens, is smaller than OpenClaw's own instructions.

How do your connections reach OpenClaw?

Over ACP, the Agent Client Protocol, as they reach every harness: Link's bridge, then the harness hub in lnk-openclaw serve, then openclaw acp over stdio, which forwards each prompt to its gateway. OpenClaw runs none of its channels, so one bot's credential has one reader, a switch or a move never has two harnesses polling it, and its Slack and Discord, whose sockets couldn't use Link's proxy, no longer ask for the network as it is.

How a chat is kept

Each chat is an ACP session of openclaw acp, a gateway session behind it, which the hub keeps by the chat's thread and takes up again after a restart. The hub's key is Link's key for the start, the gateway's token too, which only the bridge holds; the gateway's own chat completions stay off.

Who runs its scheduled jobs?

Link's scheduler, as for every harness whose contract says from: a schedule's message reaches OpenClaw over ACP, said as the schedule's, and its answer goes where the schedule says. OpenClaw's own cron is off (cron.enabled: false), as its channels are, so no job fires twice.

What does it need beyond Link's defaults, and when?

No sandbox only with OpenAI on a Mac, where Codex's runtime runs ps, which no macOS sandbox runs. An agent on any connection with Anthropic runs with Link's defaults.

Why is its browser off without the sandbox, or with `--network-mode host`?

Because there its managed browser's debugging port asks for no credential on the machine's loopback, where every user and program reaches it, and so drives the browser as you. Its other browser ports ask for a token, or don't open in the sandbox.

Off by default

OpenClaw runs well without its browser, so the safe answer is the default: needs names it as a risk it runs without, browser, and only your yes in a terminal, or lnk agent harness allow browser --harness openclaw, turns it on.

Where it stays on

In the sandbox on a Mac it stays on, since OpenClaw finds no Chrome to start there; on Linux it stays on behind its proxy, where the port stays in the sandbox's network.

How the adapter knows

Link tells the adapter whether it runs behind its proxy (proxied in its settings), so --network-mode host is asked about as no sandbox is, and it takes a Link that doesn't say as no proxy.

How does OpenClaw get a secret in its config?

By variable: a value in its config that holds a secret names a variable of its .env (${LNK_OPENCLAW_GATEWAY_TOKEN}, ${LNK_OPENCLAW_MODEL_URL}), which OpenClaw reads as it loads its config, so openclaw config set never has one on its command line, where every user of the machine sees it.

The model's address

The model's address is one, since a model on this machine is reached through its proxy with the proxy's secret in its path. OpenClaw refuses a config naming a variable that isn't set, so the model's address stays in .env until no provider's entry names it.

Its tools' addresses

Its tools' addresses, which hold the secret too, are written into its config file itself (600), by this adapter rather than openclaw config set.

Which of OpenClaw's bugs does it work around?

A bug in the OpenClaw release the adapter pins is worked around in the adapter's src/workarounds/, apart from the code meant to stay, each naming the bug and its report to OpenClaw. A workaround goes once the pin moves to a release that fixes its bug.

Its sessions' ids over ACP

OpenClaw 2026.9.6's openclaw acp confuses a session's ACP id with its gateway key, acp-bridge:<id>. A session/resume after a restart binds the session to a new, empty one, and session/list names each session by its key. Between the hub and openclaw acp, the adapter takes resume out of what it offers, so the hub takes a session up with session/load, which finds it, and gives a list's sessions their ids. So a chat goes on after OpenClaw restarts, and a switch away carries each chat as the thread it was.