https://github.com/GoogleCloudPlatform/scion

For observability, would be amazing to have session replay or at least session exploration built in. Kinda like git history but tied to tasks and tool use instead of file diffs.

[Edit] When claude spawns sub-agents, they inherit the parent's hooks. So all sub-agents activity gets logged by default.

Node has a 30-50ms cold start overhead. Then there's overhead in the hook script to read local config files, make http request to server, and check for callbacks. In practice, this was about 50-60ms per hook.

The background hook shim reduces latency to around 3-5ms (10x improvement). It was noticeable when using agent teams with 5+ sub-agents running in parallel.

But the real speed up was disabling all the other plugins I had been collecting. It piles up fast and is easy for me to forget what's installed globally.

I've also started periodically asking claude to analyze it's prompts to look for conflicts. It's shockingly common for plugins and skills to end up with contradictory instructions. Opus works around it just fine, but it's unnecessary overhead for every turn.

It's super important to check your plugins or use a proxy to inspect raw prompts. If you have a lot of skills and plugins installed, you'll burn through tokens 5-10x faster than normal.

Also have claude use sub-agents and agent teams. They're significantly lighter on token usage when they're spawned with fresh context windows. You can see in Agents Observe dashboard exactly what prompt and response claude is using for spawning sub-agents.

Basic flow:

1. Plugin registers hooks that call a dump pipe script that sends hook events data to api server

2. Server parses events and stores them in sqlite by session and agent id - mostly just stores data, minimal processing

3. Dashboard UI uses websockets to get real-time events from the server

4. UI does most of the heavy lifting by parsing events, grouping by agent / sub-agent, extracting out tool calls to dynamically create filters, etc.

It took a lot of iterations to keep things simple and performant.

You can easily modify the app/client UI code to fully customize the dashboard. The API app/server is intentionally unopinionated about how events will be rendered. This was by design to add support for other agent events soon.

https://github.com/simple10/agents-observe

The next big layer for my personal stack is full orchestration. Something like Paperclip but much more specialized for my use cases.

A few interesting learnings from building and using this:

- Claude code hooks are blocking - performance degrades rapidly if you have a lot of plugins that use hooks

- Hooks provide a lot more useful info than OTEL data

- Claude's jsonl files provide the full picture

- Lifecycle management of MCP processes started by plugins is a bit kludgy at best

The biggest takeaway is how much of a difference it made in claude performance when I switched to background (fire and forget) hooks and removed all other plugins. It's easy to forget how many claude plugins I've installed and how they effect performance.

The Agents Observe plugin uses docker to start the API and dashboard service. This is a pattern I'd love to see used more often for security (think Axios hack) reasons. The tricky bit was handling process management across multiple claude instances - the solution was to have the server track active connections then auto shut itself down when not in use. Then the plugin spins it back up when a new session is started.

This tool has been incredibly useful for my own daily workflow. Enjoy!

Comments URL: https://news.ycombinator.com/item?id=47602986

Points: 76

# Comments: 28

We'll know for sure when they add full OpenClaw-like features to Claude Code like remote channels & heartbeat support. Both are partially implemented already.

Here's the full (unedited) details including many of the claude code debugging sessions to dig into the logs to figure out what happened:

https://github.com/simple10/openclaw-stack/blob/caf9de2f1c0c...

And here's a summary a friend did on a fork of my project:

https://github.com/proclawbot/openclaude/blob/caf9de2f1c0c54...

The full version has all the build artifacts Opus created to perform the jail break.

It also has some thoughts on how this could (and will) be used for pwn'ing OpenClaws.

The key takeaway: OpenClaw default setup has little to no guardrails. It's just a huge list of tools given to LLM's (Opus) and a user request. What's particularly interesting is that the 130 tool calls never once triggered any of Opus's safety precautions. For its perspective, it was just given a task, an unlimited budget, and a bunch of tools to try to accomplish the job. It effectively runs in ralph mode.

So any prompt injection (e.g. from an ingested email or reddit post) can quickly lead to internal data exfiltration. If you run a claw without good guardrails & observability, you're effectively creating a massive attack surface and providing attackers all the compute and API token funding to hack yourself. This is pretty much the pain point NemoClaw is trying to address. But its a tricky tradeoff.

It's a neat piece of architecture - the OpenShell piece that does the security sandboxing. Gives a lot more granular control over exec and network egress calls. Docker doesn't provide this out of the box.

But NemoClaw is pre-configured to intercept all OpenClaw LLM requests and proxy them to Nvidia's inference cloud. That's kinda the whole point of them releasing it.

I can be modified to allow for other providers, but at the time of launch, there was no mention of how to do this in their docs. Kinda a brilliant marketing move on their part.

The short of it - OpenClaw sandboxes are useful for controlling what sub-agents can do, and what they have access to. But it's a security nightmare.

During config experiments, I got hit with a $20 Anthropic API charge from one request that ran amuck. Misconfigured security sandbox issue resulted in Opus getting crazy creative to find workarounds. 130 tool calls and several million tokens later... it was able to escape the sandbox. It used a mix of dom-to-image sending pixels through the context window, then writing scripts in various sandboxes to piece together a full jailbreak. And I wasn't even running a security test - it was just a simple chat request that ran into sandbox firewall issues.

Currently, I use sandboxes to control which agents (i.e. which system prompts) have access to different tools and data. It's useful, but tricky.

Comments URL: https://news.ycombinator.com/item?id=47343419

Points: 2

# Comments: 0

I spent the past month hacking on openclaw to play nice in a docker container for my own VPS use.

This project has a lot of useful debugging tools for running multiple claws on a single VPS:

https://github.com/simple10/openclaw-stack

For average users, Klaus is a much better fit.

Comments URL: https://news.ycombinator.com/item?id=47059920

Points: 3

# Comments: 3