Debugging on Margrop Blog

One Missing operator.write Took Down the Gateway: The OpenClaw Fallback Failure That Wasn't a Model Problem

Fri, 10 Jul 2026 08:00:00 +0800

This incident looked like a model-provider outage at first. OpenClaw had just received three NewAPI-backed fallback models, but gateway-based model calls started failing with a provider authentication error. After peeling back the outer message, the real error was much more specific:

missing scope: operator.write

That string changed the direction of the investigation. The provider key was not the root problem. The NewAPI endpoint was not the root problem. The model names were not the root problem either. The failure lived inside OpenClaw’s gateway authorization path: when a model override was used, the gateway call switched into a backend/gateway-client mode, but did not force the request to use the already paired stored device identity. The device had operator.write; the request simply did not carry the identity that could prove it.

The shortest version is this: the badge existed, but this entrance did not scan it.

PhotoPrism Stuck for 5 Minutes on First Boot? A Postmortem on PHOTOPRISM_INIT=intel

Sat, 13 Jun 2026 08:30:00 +0800

TL;DR (The Short Version)

The PHOTOPRISM_INIT: "intel" line in PhotoPrism’s Plus Docker image is not just a flag to enable Intel hardware acceleration at runtime — it’s a one-shot system-level installer that runs apt-get dist-upgrade against archive.ubuntu.com and then installs 8 Intel/VA-API packages before the main process is allowed to start. On a fresh container this takes 5–10 minutes (sometimes more), during which nothing inside the container listens on port 2342.

Meanwhile: docker ps says Up, Portainer is green, ss -ltn on the host shows :2342 LISTEN — but your browser gets ERR_CONNECTION_RESET / Connection reset by peer. Because host-side docker-proxy accepts the connection and then tries to forward to a port inside the container that has no listener, the kernel sends back an RST.

Fix: just remove or empty that one line. If you already pass /dev/dri/renderD128 via devices:, the host’s drivers and userland libraries are perfectly usable from the container — there’s nothing to “install” in there.

OpenClaw TUI Keeps Repeating Itself? A Temporary Patch for Duplicate Thinking and Replies

Tue, 02 Jun 2026 10:42:00 +0800

The short version

If OpenClaw TUI shows the same thinking block twice and repeats the final answer, do not immediately delete every session or rebuild every model provider. In many OpenAI-compatible setups, the real issue is a streaming compatibility edge case: the upstream stream emits normal delta chunks and then an extra full message tail. Some OpenClaw paths may aggregate both, so the TUI and the persisted session both end up with duplicated content.

The practical temporary fix is to back up the local OpenClaw installation, add a conservative dedupe guard in the OpenClaw aggregation layer, restart the gateway, and verify with a unique marker that both the visible reply and the session file contain only one copy.

This is a privacy-safe incident note. All endpoints, model names, tokens, internal addresses, and session identifiers are replaced by placeholders. Use your own installation path and model identifiers when applying the workaround.

Double-Consumed Streaming: Debugging a NewAPI v1.0.0-rc.10 MiniMax Proxy Bug

Sun, 31 May 2026 18:00:00 +0800

TL;DR

An AI Agent was producing duplicated replies in DingTalk — not two separate messages, but a single message whose content appeared twice. The root cause traced back to a streaming bug in NewAPI (the QuantumNous fork of OneAPI) v1.0.0-rc.10: when proxying MiniMax through the OpenAI Chat Completions protocol, the finish chunk contained both delta.content and message.content with identical values. The Agent’s stream handler consumed both as “visible text,” concatenating the content twice. The fix was straightforward: switch the OpenClaw provider protocol from openai-completions to anthropic-messages, which OneAPI natively supports and where streaming behaves correctly.

No internal IPs, tokens, model IDs, or private paths appear in this article. All configuration snippets have been sanitized.

Why HermesAgent Would Not Reply in WeChat or WeCom: The Real Culprit Was a Local Relay With a 3-Second Timeout

Sun, 31 May 2026 08:00:00 +0800

The short version

This incident looked like a model problem or a broken messaging channel, but the real failure happened one layer lower: my local relay cut the upstream request off after 3 seconds. That was fine for quick health checks, but it was wrong for real WeChat and WeCom turns, which often take longer to produce a complete answer from the NewAPI gateway. Once the relay disconnected too early, HermesAgent could only see Connection error, RemoteProtocolError, and then exhausted fallback attempts.

Mystery: Where Did That http_proxy Come From in My New Tmux Session?

Sat, 30 May 2026 16:00:00 +0800

Preface

Today I ran into a truly bizarre problem: in a freshly created tmux session, echo $http_proxy showed a valid proxy address. But I distinctly remember that my .zshrc only defines two aliases — proxy_on and proxy_off — both of which require manual invocation and don’t run automatically.

The weirdest part: my main shell shows http_proxy as empty, but as soon as I enter tmux, it’s there. I spent nearly an hour tracking this down, so I’m documenting it for posterity.

Python App in macOS LaunchAgent Can't Reach the Internet? Here's the httpx Proxy Trap You Need to Know

Sat, 30 May 2026 09:00:00 +0800

TL;DR:

When a Python application using httpx with trust_env=True runs inside a macOS LaunchAgent, it silently picks up the system proxy settings from scutil --proxy. But the LaunchAgent process may not be able to reach that proxy server at all — resulting in All connection attempts failed or No route to host errors.

The fix is one line: add NO_PROXY=* to the LaunchAgent’s plist EnvironmentVariables.

This article documents the full debugging journey: from discovering that my AI Agent’s WeChat Enterprise (WeCom) messages weren’t being replied to, through methodical proxy troubleshooting, to finally pinning down the root cause — macOS system proxy + LaunchAgent network isolation. We’ll dive deep into Python httpx source code, macOS proxy architecture, and the many gotchas of LaunchAgent runtime environments.

Why My AI Assistant Repeated One Reply Four Times: Debugging an OpenClaw WeChat Channel Issue

Fri, 29 May 2026 11:24:29 +0800

Short version

The symptom looked like a messaging-channel bug: an AI assistant connected to a personal chat channel appeared to repeat the same reply multiple times. The real bug was earlier in the chain. Before the reply ever reached the message-sending layer, the OpenClaw agent had already produced duplicated visible text. The useful fix was not to patch the chat sender blindly, but to split the path into transport, session, model-routing, and provider layers, then compare the OpenAI-compatible gateway path with the native provider path. Once the faulty compatible provider candidate was removed from the visible model set and the personal IM channel was pinned to the native provider, the same minimal prompt returned exactly once.

This post is deliberately privacy-safe. It contains no real internal addresses, account IDs, tokens, session IDs, personal chat identifiers, or private file paths. Configuration examples use placeholders. The value is the debugging method, not the private environment.