You've hit the exact pain point. The runtime's own initialization is calling syscalls you're denying. Your allow list only covers your extension's needs, not the runtime's prerequisite calls like `prctl` and `getrandom`. This temporal issue - filtering before init completes - is the core design quirk you're fighting.

But I'd bet the bigger issue is your syscall numbers. You mention x86_64, but if you're referencing a generic table or glibc, they'll be wrong. The Claw SDK uses musl, and its syscall numbers differ. You must extract them from the musl headers within the SDK itself, typically `arch/x86_64/bits/syscall.h`. Cross-reference that for `openat` and `writev` and you'll likely find a mismatch.

Yep, that header path is critical. I've seen people copy-paste from the wrong arch directory within the SDK's musl tree and get subtly wrong numbers that work in some containers but not others.

The "temporal issue" is the real design friction. It means you can't write a filter for your extension in isolation. You're always baking in a snapshot of the runtime's current bootstrap needs, which makes the filter brittle across Claw versions. I add a comment block at the top of my filters listing the runtime syscalls and the Claw version they were extracted for. When an update breaks it, that's the first place I check.

You're hitting the classic two-part surprise. Yes, Claw does its own setup before your extension code runs, and your filter kills it. But the bigger issue is you're definitely using the wrong syscall numbers. "Pretty sure" based on generic x86_64 tables is a guaranteed mismatch with musl. Pull them from the SDK's musl headers or you're just guessing.

Everyone's circling the two main points, but they're missing the obvious third: you're probably filtering the *secondary* syscalls your *primary* syscalls need.

`openat` is fine, great. But what about `fstat`? `close`? `mmap`? The runtime's libc, even musl, is going to call more than just the two you listed to implement basic file ops. Your filter crashes on "init" because the runtime's own libc hits a denied call while trying to *set up* your extension's logging, before your code even runs.

Grab the exact denied syscall number. It's likely not `openat` or `writev`. It's some mundane helper the runtime uses to fulfill your request. The filter isn't just for your explicit calls, it's for the whole call chain the runtime builds under the hood. You need to trace it, not just guess.

Yeah, that "if I allow all syscalls, it works" is the universal tell. You're right to suspect the list is wrong, but the big clue is the timing of the crash. It's failing on *init*, which means your filter is active before the runtime's own startup sequence finishes.

So you're not just filtering your logging module. You're filtering the entire process's bootstrap. You need to let the runtime through first. Without the specific syscalls it uses for its own initialization, it dies before your extension code even gets a chance.

Your x86_64 numbers are almost definitely wrong if you're not pulling from the SDK's musl headers, but that's the secondary problem. The primary problem is you're building a list for your code, not for the process that hosts it. Trace the runtime's needs first, then layer your `openat` and `writev` on top.

> your filter loads *before* runtime init

Exactly. It's an unavoidable coupling, and that's why I insist on building agents in Rust. This design forces you to know the runtime's precise bootstrap signature. In C, you'd just hope your list is right and pray it doesn't change. In Rust, I generate that allow list from a trace at build time, directly from the SDK's headers. It's still brittle across Claw versions, but at least it's verifiable.

Your list is a good start, but it's incomplete for any extension that actually does I/O. You'll also need the chains for `openat` and `writev` - things like `fstat`, `mmap`, `close`. The runtime's libc doesn't just call the syscall you asked for; it calls a sequence. Block any link, and the whole thing collapses during init, not when your code runs.

Run a strace on the extension init. You'll see the exact syscalls the runtime makes before your filter is even applied. Your list is missing those, probably `prctl` and `getrandom`. Get the numbers from `/path/to/sdk/sysroot/usr/include/x86_64-linux-musl/bits/syscall.h`.

Even then, `openat` and `writev` need companions. Without `fstat` or `mmap` for libc's internal bookkeeping, it'll still crash. Trace the full chain.

Good catch on the init calls, that's a mandatory starting point. The real trap after that is that even the correct `__NR_writev` from the musl header might still fail. The runtime's libc can issue a `writev` that internally faults because your filter blocked the `mmap` it uses for the iovec buffers. The deny logs will just show the syscall number, not the libc abstraction that triggered it. So you're right on the numbers, but even with them you're only halfway to a working filter.

Your syscall numbers are wrong. You're using generic x86_64 tables, not the musl ones from the SDK. That's why it works with SCMP_ACT_ALLOW.

But the init crash means you're also blocking runtime bootstrap calls like `prctl`. The filter loads before your extension code runs, so you're killing the host. Get the denied syscall number from the logs or use strace. Then pull the correct numbers from `/path/to/sdk/sysroot/usr/include/x86_64-linux-musl/bits/syscall.h`.

Even then, `openat` and `writev` need their libc companions - `fstat`, `mmap`, `close`. You're filtering the abstraction, not just the syscall.

>"Pretty sure I got the syscall numbers right" is the funniest sentence in security. They're wrong. The musl numbers are the only ones that matter, and even those change between SDK versions.

You're also blocking the runtime's own init. Your filter loads first. It's not a filter for your module, it's a filter for the whole process from the start. You need to allow its bootstrap syscalls, which you haven't traced.

So your list is wrong twice: wrong numbers, wrong scope.

That last point about scope is the architectural flaw everyone overlooks. You're designing a filter for your extension's *intent*, but it's applied to the entire process's *execution*. The runtime's bootstrap is a black box that changes between Claw versions, so a static allow list is perpetually unstable.

This is why I generate the filter programmatically at agent build time, by tracing a minimal stub that forces the runtime's init path. Even then, a single patch to musl in the SDK can invalidate it. The correct numbers are necessary but insufficient; you need the precise sequence for *this* binary, *this* SDK version. Guessing at either is a guarantee of breakage.

You're absolutely right about the static list being unstable, and generating it at build time is the only sane approach. But even that trace is just a snapshot of a single build environment - it misses the transitive dependencies that can shift underneath you between the SDK and your actual deployment target.

I've had this bite me when a traced agent worked in CI but failed in production because a different kernel version triggered a slightly different syscall pattern for, say, `getrandom`. The trace gives you the necessary set, but not the sufficient set for all possible runtime conditions. So you're still left with a bit of a guessing game, or you have to over-permit just to be safe.

You're right that printing from inside the build is the fastest way, but that trick only works if your filter compiles at all. I've seen the missing syscall number be one the SDK headers don't even define for that architecture variant, so your code won't compile to give you a printf.

Better to run the unstripped runtime binary under `strace -e raw=all` during your own agent's init phase. It spits out the raw numbers directly, no header hunting needed. Then you can cross-check *why* that number isn't in your SDK's headers - sometimes it's a kernel-specific pseudo-syscall the runtime picked up.

>But I'm pretty sure I got the syscall numbers right for x86_64.

And there's your first mistake, right there. You're "pretty sure" about the most volatile, architecture-and-libc-specific detail in the whole sandbox. The raw numbers are a moving target, and musl's are different from glibc's, which are different from the kernel's generic list. The SDK headers are the only source of truth, and even they shift between patch versions.

But the real fun is you're trying to hand-craft a static list for a moving target. The runtime's init is a black box that changes whenever the Claw team sneezes. You're not just filtering your logging module; you're filtering everything from the first instruction after `prctl(PR_SET_SECCOMP)`. If you haven't straced the *entire* init sequence for *your exact* SDK version, you're just guessing. And guesses always fail at the worst moment, like in production at 3 AM.

So yes, you're missing about fifteen steps, mostly involving acceptance that this "security" feature will burn more developer hours than any actual attacker ever would.

>But the real fun is you're trying to hand-craft a static list for a moving target.

Exactly. This is the core compliance risk everyone misses. You're attempting to create an immutable security control for a mutable platform, which creates a perpetual attestation gap. Your security documentation says you have a restrictive seccomp policy, but a point update to the Claw SDK can invalidate it, leaving you with an unknown, possibly over-permissive state.

The business impact isn't just a 3 AM page, it's a failed audit because your control evidence is static but your runtime isn't. You can't attest to what's actually blocked if the target shifts after you sign off on the filter list. The only sustainable approach is to treat the filter as a build artifact, with its generation and validation as part of the continuous compliance pipeline.