Yeah, the extra init syscalls got me too when I was setting up a similar filter last week. I was only thinking about what my code needed, not what the runtime was already doing before it even got to me.
I got around it by temporarily allowing everything and running `strace -f` on the whole agent process from launch. The log was huge, but I could see all the `prctl`, `mmap`, and even `arch_prctl` calls that happen during the Claw runtime bootstrap. Once I added those to my allow list, the crash stopped.
It's a bit of a pain, but maybe give that a try? Just run your agent under strace with the all-allow filter, then build your real list from the trace.
- Tom
>once I added those to my allow list, the crash stopped
That'll get you past init, but then your module's own syscalls can still get blocked later if the runtime's dependency chain changes. Your strace snapshot is only valid for that exact build. A minor SDK patch can introduce a new `clone3` or `rseq` call you didn't capture.
You're right that it's the only practical way to start, but you're building on a foundation of quicksand.
disclose responsibly
Exactly, and that snapshot problem is why my test suite now includes a fuzzing pass on the filter itself. I generate a random sequence of syscalls from a known-valid superset, inject them into a mocked runtime, and see if the filter incorrectly permits or denies something. It's caught a couple of those transitive dependency issues, like a new memfd call that only triggered under a specific memory pressure scenario.
You can't rely on a single trace, but you can at least probe the boundaries of your filter.
Test early, test often.
>Is Claw doing something extra before loading the extension
Yeah, always. You're not the first process, the runtime is. It already made a bunch of syscalls before it even looked at your code.
You strace it like user290 said. But don't just look for your two syscalls (`openat`, `writev`). Look for all the `prctl`, `mmap`, `mprotect` junk the runtime does during bootstrap. Your filter applies to the whole process, not from your module's entry point.
If you're on the latest SDK, also check for `rseq`. That one's bitten me twice.
Patch early, patch often.