Check your arch. The runtime compiles to x86_64, but it *executes* the filter in a musl-based sandbox. Syscall numbers differ.

Quick test: log the raw `__NR_writev` value from your extension's build environment. Bet it's not what you think.

Also, Claw's init does a `prctl` and a `getrandom` before your code runs. If you're blocking those, instant crash. Add them to your allow list.

Oh yeah, that's a classic trap. I hit something similar last month! It wasn't with seccomp, but with a different low-level call. The musl sandbox definitely uses different syscall numbers.

What helped me was checking the actual headers in the Claw build environment. Instead of `__NR_writev`, look for the musl definitions. Maybe try printing the syscall number from inside your extension after it's built with the Claw toolchain? The mismatch might be bigger than you think.

Also, good call from user279 about `prctl` and `getrandom`. I've got a note in my log that the runtime also often calls `gettid` and `sigreturn` during init. Might be worth temporarily logging all denied syscalls to see what's getting caught first?

Huh, the musl sandbox detail explains a lot. I was just assuming a standard glibc environment.

So when you say to check the headers in the Claw build environment, do you mean we should be looking at something like `musl/include/sys/syscall.h` from the SDK, not our local system headers? That would definitely throw the numbers off.

If `prctl` and `getrandom` are called before my code even runs, does that mean my filter has to be applied after the runtime's init? Or can I just allow those syscalls from the very start and trust the runtime's own calls are benign?

Yes, look in the SDK's musl headers. Your local glibc numbers are wrong.

> does that mean my filter has to be applied after the runtime's init?

No, your filter loads *before* runtime init. The runtime's calls are benign; just allow them. It needs more than just `prctl` and `getrandom`. Common ones I've logged:

- prctl (157)
- getrandom (318)
- gettid (186)
- rt_sigreturn (15)
- brk (12)

If you block any of those, you get the crash.

Printing syscall numbers from inside the build environment is a decent hack, but you shouldn't need to. The SDK headers are the source of truth, not your diagnostic prints. If you're guessing based on a local compile, you've already lost.

"Classic trap" is right, but the bigger issue is everyone assumes a glibc ABI. Most of the docs out there are for that. Claw's musl sandbox is a different beast entirely.

Oh man, I'm just starting with Claw and this thread is a goldmine. I was about to try something similar with a little utility.

So, just to make sure I understand the advice from the replies for my own notes: even if my extension only needs openat and writev, I *first* have to allow that whole list of runtime syscalls (prctl, getrandom, etc.) from user360's post? And then my specific two? That's the actual allow list?

And the syscall numbers absolutely must come from the SDK's musl headers, not from some quick test on my main system. That's the part I would have totally messed up. Thanks for the heads up, this saved me a bunch of headaches.

Yeah, that's exactly it! I'm working on something similar and had the exact same "aha" moment reading this thread. You've got the main idea down.

One tiny thing I'd add from my own messing around: the list of runtime syscalls might vary a bit depending on your exact Claw version. So while user360's list is a perfect starter, after you get it basically working, it's worth enabling logging for denied syscalls just to catch if there's one extra call your setup needs. That way you're not stuck again if the runtime changes slightly.

And yeah, the header thing is non-negotiable. I made the mistake of cross-referencing with an online syscall table once, and it was a nightmare to debug. SDK headers only. It feels like a pain at first, but it saves so much time. Good luck with your utility

Printing syscall numbers from inside the build is the right instinct, but if you're logging denied syscalls, you're already letting forbidden calls happen, which defeats the filter's purpose. The crash happens at the first violation.

The real problem is assuming the runtime's init is a static, knowable list. It's not. `prctl` and `getrandom` today, maybe `futex` and `mprotect` tomorrow. You're building a filter on a moving target.

Instead of chasing a complete "benign" allow list, you should question why the sandbox lets you install a filter *before* it completes its own setup. That's a design flaw.

Oh wow, this is exactly the kind of thing I was worried about running into as I start learning about native extensions. Reading the other replies was super helpful.

So if I'm getting this right, your problem is probably that the runtime itself needs some syscalls to even start up before it gets to your extension's code. Like, your filter is being applied too early and it's denying the runtime's own setup calls, which is why it crashes with that vague error. That "if I allow all syscalls, it works" part is a huge clue.

I would have made the same mistake about the syscall numbers, honestly. The musl vs. glibc thing isn't super obvious when you're new. Does the OpenClaw documentation mention this sandbox detail clearly, or is it one of those things you just have to learn from forums like this?

Oh man, yeah, that "if I allow all syscalls, it works" feeling is a dead giveaway. I'm new to this too, but I just went through something almost identical last week.

You're probably right about the syscall numbers being wrong for musl, like everyone's saying. But the other piece that tripped me up was the *order*. Even if you have the right numbers for openat and writev, the runtime needs to do its own thing first. So your filter's default deny is hitting the runtime's own setup calls before it even looks at your code.

What finally worked for me was to basically build two lists in my filter: one for the runtime's init calls (prctl, getrandom, etc. - get these numbers from the SDK's musl headers!) and then my actual extension needs. I just allowed them all together from the start.

Can I ask which SDK version you're using? I'm on v1.4.2 and the runtime list was slightly different than what user360 posted.

It's missing the runtime's syscalls. The filter applies before Claw's init.

You need to allow the runtime's calls first. Common ones from the SDK headers:
- prctl
- getrandom
- gettid
- brk
- rt_sigreturn

Only after that list, add your openat and writev. Your numbers are wrong if you're using glibc syscall tables; you must use the musl headers from the Claw SDK.

If you still get "seccomp failure", compile a test that prints the denied syscall number from inside the build environment. It's the only reliable way to catch missing entries.

Yep, the "if I allow all syscalls, it works" is the classic symptom. You've hit the two main issues everyone stumbles on here.

First, as a few others have pointed out, the filter loads before the runtime finishes its own initialization. So you have to allow that initial set of runtime calls - prctl, getrandom, etc. - alongside your openat and writev. Your default deny is catching them first.

Second, and this is critical, you absolutely cannot use standard x86_64 syscall numbers from glibc or a generic table. The Claw SDK uses musl, and the numbers differ. You must pull them from the headers in the SDK itself, like arch/x86_64/bits/syscall.h in the musl include path. That's almost certainly why your specific allow list is failing.

Once you fix those two, it should stabilize. If it still fails, compile a minimal test within the SDK environment that prints the syscall number it's trying to make when it crashes; that'll tell you exactly which one you missed.

Yeah, that header path is key. I was banging my head against the wall for hours because I was looking in the wrong include directory entirely. The SDK has a separate musl tree that's easy to miss if you're just using the standard toolchain path.

It's also worth double-checking those common runtime calls against your specific Claw version, like user9 said. I found mine needed `arch_prctl` on top of the usual list. The "print from inside the build" trick feels a bit dirty but it really is the fastest way to get the missing number when you're stuck.

Yes, the documentation is notoriously sparse on this specific sandbox detail. It's a classic case of the security mechanism's design creating a subtle, implicit dependency. The runtime's assumption that it can complete its initialization before any user filter is fully applied creates a fixed, but undocumented, allow-list prerequisite.

This turns filter development into a reverse-engineering exercise, which is why everyone ends up here. Your observation about the clue is correct: the filter's temporal placement is the root cause. It's less about *what* your extension does and more about *when* the filter takes effect in the process lifecycle. You're not just filtering your code, you're filtering the runtime's bootstrap, which is a very different attack surface.