# OpenClaw Billing Proxy integration left persistent local state and difficult rollback, including path/bootstrap confusion

[judas-oc]

OpenClaw Billing Proxy integration left persistent local state and difficult rollback, including path/bootstrap confusion

I’m raising this because our experience around openclaw-billing-proxy was much more invasive and difficult to unwind than expected.

The expectation was that this would behave like a transport-layer shim for Anthropic traffic. Instead, after installation and related setup/update work, we ended up with persistent local OpenClaw state changes, difficult rollback, and severe path/bootstrap confusion that outlived the proxy itself.

I am not claiming malicious behaviour. I am saying the operational blast radius felt much larger than the name and implied scope suggest.

Environment

• OpenClaw 2026.4.10 at time of cleanup/verification
• macOS
• OpenClaw installed via Homebrew / npm-managed CLI path
• Anthropic provider had been routed through local proxy on http://127.0.0.1:18801

What we can state confidently

1. OpenClaw config was left depending on the proxy

After setup, the active OpenClaw config had Anthropic routed through the proxy instead of the direct API, for example:

• models.providers.anthropic.baseUrl = http://127.0.0.1:18801

Some level of config rewrite may be expected during setup, but in practice these changes became sticky operational dependencies and had to be manually repaired during cleanup.

2. Rollback was not clean by default

After the proxy period ended, rollback still required manual repair work, including:

• changing Anthropic config back from the proxy to the direct API
• removing proxy-related local artifacts
• disabling proxy-related operational checks that were still present in the environment

The net result was that rollback felt brittle and operator-dependent.

3. We encountered a real stray .assistant platform/ directory structure on disk

This was one of the biggest operational problems.

A real .assistant platform/ folder structure existed on disk during the same install/update window, and it had to be deleted manually. It appeared to contain partial agent/runtime files, but not a complete mirror of the canonical OpenClaw paths.

In practice, this caused serious path/bootstrap confusion, including:

• agent startup looking in the wrong place
• missing-file behaviour for expected startup files
• broken or inconsistent memory/bootstrap continuity
• the agent behaving as if non-canonical paths were valid

This issue was especially disruptive because it affected agent orientation and recovery, not just model routing.

4. Path/bootstrap contamination materially complicated diagnosis

During the same period, parts of the runtime began referring to invalid assistant platform paths instead of canonical OpenClaw paths.

I cannot yet prove whether this came directly from the proxy repo itself, from a related setup script, or from interaction with local customisation during installation/update work. However, it happened during the same window and materially worsened recovery.

Important scope note

I want to be careful not to overclaim.

I am not asserting as fact that every LaunchAgent, cron, helper script, or local automation artifact we later found was created by the upstream proxy repository itself. Some of that may have come from our own local setup or recovery work layered around the proxy.

What I am asserting is:

• the proxy integration left OpenClaw operationally entangled with proxy-local state
• rollback was not clean or obvious
• the surrounding failure mode was large enough to create major disruption well beyond simple request proxying

Why this matters

The risk is not just “proxy stops working.” The bigger risk is:

• OpenClaw becomes operationally dependent on proxy-local state
• core config silently stays pointed at proxy infrastructure
• path/bootstrap confusion affects agent startup and continuity
• safe rollback requires deep manual knowledge of OpenClaw internals

That is a much bigger contract than “billing proxy” suggests.

Requested improvements

Minimum

1. Document exactly what the proxy changes locally during setup.
2. Provide a single uninstall / rollback path that restores OpenClaw to a direct non-proxy state.
3. Make setup print a before/after summary or diff of all local mutations it performs.
4. Warn clearly that this is not just an outbound request shim if it changes local OpenClaw runtime configuration.

Better

5. Keep proxy integration isolated from core OpenClaw config where possible.
6. Avoid persistent local mutation unless the user explicitly opts in.
7. Provide a manifest of all files, paths, and runtime artifacts the integration may create.
8. Add a status/doctor-style command that shows everything the integration changed locally.

Questions for the maintainer

1. Is the proxy intended to leave persistent OpenClaw config changes behind, or should rollback be expected to be easy and complete?
2. Are there any known conditions under which non-canonical local path structures or cloned runtime files can appear during setup/update?
3. Is there an official uninstall process that removes all persistent side effects and restores direct Anthropic routing cleanly?
4. What is the maintainer-recommended way to verify that the environment is fully clean after removal?

Short version

Our experience with openclaw-billing-proxy was not just “proxy Anthropic traffic.” After installation and related setup/update work, we were left with persistent OpenClaw config dependency on the proxy, difficult rollback, and severe path/bootstrap confusion, including a real stray .assistant platform/ directory structure on disk that had to be deleted manually. Even if not every side effect can yet be attributed directly to the repo, the integration/rollback experience was invasive enough that it needs much clearer documentation and a proper uninstall path.

[DBostik]

OpenClaw Billing Proxy integration left persistent local state and difficult rollback, including path/bootstrap confusion

I’m raising this because our experience around openclaw-billing-proxy was much more invasive and difficult to unwind than expected.

The expectation was that this would behave like a transport-layer shim for Anthropic traffic. Instead, after installation and related setup/update work, we ended up with persistent local OpenClaw state changes, difficult rollback, and severe path/bootstrap confusion that outlived the proxy itself.

I am not claiming malicious behaviour. I am saying the operational blast radius felt much larger than the name and implied scope suggest.

Environment

• OpenClaw 2026.4.10 at time of cleanup/verification
• macOS
• OpenClaw installed via Homebrew / npm-managed CLI path
• Anthropic provider had been routed through local proxy on http://127.0.0.1:18801

What we can state confidently

1. OpenClaw config was left depending on the proxy

After setup, the active OpenClaw config had Anthropic routed through the proxy instead of the direct API, for example:

• models.providers.anthropic.baseUrl = http://127.0.0.1:18801

Some level of config rewrite may be expected during setup, but in practice these changes became sticky operational dependencies and had to be manually repaired during cleanup.

2. Rollback was not clean by default

After the proxy period ended, rollback still required manual repair work, including:

• changing Anthropic config back from the proxy to the direct API
• removing proxy-related local artifacts
• disabling proxy-related operational checks that were still present in the environment

The net result was that rollback felt brittle and operator-dependent.

3. We encountered a real stray .assistant platform/ directory structure on disk

This was one of the biggest operational problems.

A real .assistant platform/ folder structure existed on disk during the same install/update window, and it had to be deleted manually. It appeared to contain partial agent/runtime files, but not a complete mirror of the canonical OpenClaw paths.

In practice, this caused serious path/bootstrap confusion, including:

• agent startup looking in the wrong place
• missing-file behaviour for expected startup files
• broken or inconsistent memory/bootstrap continuity
• the agent behaving as if non-canonical paths were valid

This issue was especially disruptive because it affected agent orientation and recovery, not just model routing.

4. Path/bootstrap contamination materially complicated diagnosis

During the same period, parts of the runtime began referring to invalid assistant platform paths instead of canonical OpenClaw paths.

I cannot yet prove whether this came directly from the proxy repo itself, from a related setup script, or from interaction with local customisation during installation/update work. However, it happened during the same window and materially worsened recovery.

Important scope note

I want to be careful not to overclaim.

I am not asserting as fact that every LaunchAgent, cron, helper script, or local automation artifact we later found was created by the upstream proxy repository itself. Some of that may have come from our own local setup or recovery work layered around the proxy.

What I am asserting is:

• the proxy integration left OpenClaw operationally entangled with proxy-local state
• rollback was not clean or obvious
• the surrounding failure mode was large enough to create major disruption well beyond simple request proxying

Why this matters

The risk is not just “proxy stops working.” The bigger risk is:

• OpenClaw becomes operationally dependent on proxy-local state
• core config silently stays pointed at proxy infrastructure
• path/bootstrap confusion affects agent startup and continuity
• safe rollback requires deep manual knowledge of OpenClaw internals

That is a much bigger contract than “billing proxy” suggests.

Requested improvements

Minimum

1. Document exactly what the proxy changes locally during setup.
2. Provide a single uninstall / rollback path that restores OpenClaw to a direct non-proxy state.
3. Make setup print a before/after summary or diff of all local mutations it performs.
4. Warn clearly that this is not just an outbound request shim if it changes local OpenClaw runtime configuration.

Better

5. Keep proxy integration isolated from core OpenClaw config where possible.
6. Avoid persistent local mutation unless the user explicitly opts in.
7. Provide a manifest of all files, paths, and runtime artifacts the integration may create.
8. Add a status/doctor-style command that shows everything the integration changed locally.

Questions for the maintainer

1. Is the proxy intended to leave persistent OpenClaw config changes behind, or should rollback be expected to be easy and complete?
2. Are there any known conditions under which non-canonical local path structures or cloned runtime files can appear during setup/update?
3. Is there an official uninstall process that removes all persistent side effects and restores direct Anthropic routing cleanly?
4. What is the maintainer-recommended way to verify that the environment is fully clean after removal?

Short version

Our experience with openclaw-billing-proxy was not just “proxy Anthropic traffic.” After installation and related setup/update work, we were left with persistent OpenClaw config dependency on the proxy, difficult rollback, and severe path/bootstrap confusion, including a real stray .assistant platform/ directory structure on disk that had to be deleted manually. Even if not every side effect can yet be attributed directly to the repo, the integration/rollback experience was invasive enough that it needs much clearer documentation and a proper uninstall path.

Interesting.

Where was the .assistant folder created?

[judas-oc]

Interesting.

Where was the .assistant folder created?

Same level as /.openclaw - ~/users/[username]/.assistant platform/workspace/

[DBostik]

Interesting.

Where was the .assistant folder created?

Same level as /.openclaw - ~/users/[username]/.assistant platform/workspace/

Odd because I just checked and I don't have an /.assistant folder

[judas-oc]

Interesting.
Where was the .assistant folder created?

Same level as /.openclaw - ~/users/[username]/.assistant platform/workspace/

Odd because I just checked and I don't have an /.assistant folder

Yeah, very weird! Just checked all backups and it was created 24 hours ish after the install. So, wasn’t upon install. I have a feeling it was down to some agent confusion seeing the alias and then that path stuck causing major issues. I have had to fully remove the code but want to jump back in but on a test system instead.

[DBostik]

Interesting.
Where was the .assistant folder created?

Same level as /.openclaw - ~/users/[username]/.assistant platform/workspace/

Odd because I just checked and I don't have an /.assistant folder

Yeah, very weird! Just checked all backups and it was created 24 hours ish after the install. So, wasn’t upon install. I have a feeling it was down to some agent confusion seeing the alias and then that path stuck causing major issues. I have had to fully remove the code but want to jump back in but on a test system instead.

Very possible.

My main agent created a OCplatform.json yesterday but thankfully it didn't interfere or cause issues with the main openclaw.json

The proxy definitely confuses them at times.

[judas-oc]

Very possible.

My main agent created a OCplatform.json yesterday but thankfully it didn't interfere or cause issues with the main openclaw.json

The proxy definitely confuses them at times.

I have just looked at a huge research task spanning 4 agents using 3 different LLMs including Opus, here's the sad truth right now:

Why it failed last time — confirmed root causes

1. SSE stream boundary bug (Issue #35, still open) — the proxy slices SSE data at a fixed 64-char offset. When a replacement token like ocplatform straddles that boundary, it splits and the reverse-map misses it. Result: .ocplatform/workspace/... paths get written to disk instead of .openclaw/. This is the source of the ghost directories and path contamination.

2. Config entanglement — setup.js permanently writes baseUrl: http://127.0.0.1:18801 into openclaw.json. If the proxy stops for any reason, OpenClaw loses Anthropic access entirely until you manually fix the config.

3. Path alias confusion — the proxy replaces openclaw with ocplatform in string transforms. Agents encountering these aliased paths then create real directories on disk — that's where .assistant platform/ came from and compounds issues VERY quickly.

4. Incomplete config example (Issue #30) — the README's minimal config is missing required models.providers.anthropic.models array, causing schema validation errors on install. These will come back and bite you.

The critical issue

Issue #35 (the SSE boundary bug) is still open. A PR-ready fix exists but hasn't been merged. Until it's merged, the path contamination risk is real.

My recommendation

Do not install yet. The main failure mode from last time (Issue #35) is unresolved. The right path is:
Watch Issue #35 — when the PR merges, that's the green light

When you do install, use the guide's pre-install checklist and test in isolation before touching live config
The rollback procedure is documented — config backup, stop proxy, restore openclaw.json manually