{"version":"2.1.323","anchor":"sandboxed-hook-probe-passes-an-inherited-fd-to-bwrap","canonical_anchor":"sandboxed-hook-probe-passes-an-inherited-fd-to-bwrap","heading":"Sandboxed hooks on Linux can receive an extra file handle","tier":"internal","area":"Hooks","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/sandboxed-hook-probe-passes-an-inherited-fd-to-bwrap","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Sandboxed hooks on Linux can receive an extra file handle\n\nOn Linux, the sandbox used to test and run hooks can now be handed an extra open file handle, which is closed again afterwards\n\n**Unclear.** It is not clear what condition makes Claude Code pass the extra file handle, or what that handle is used for.\n\n**What**\n\nA hook is a command you configure for Claude Code to run automatically at certain moments. On Linux, Claude Code can run hooks inside a sandbox, which is a walled-off process with limited access to your machine.\n\nWhen Claude Code first checks whether a hook can be sandboxed, and when it wraps the hook in the sandbox, it can now pass one extra open file handle into the sandboxed process under a certain condition. A file handle is the operating system's reference to an open file or stream. Claude Code releases the handle once it is done. The part of the sandbox that filters system calls works as it did before.\n\n**Why**\n\nThis affects how hooks are sandboxed on Linux remote workers, the machines that run cloud sessions.\n\n- Area: Hooks\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}