{"version":"2.1.224","anchor":"sandboxed-commands-are-tagged-with-an-attribution-id","canonical_anchor":"sandboxed-commands-are-tagged-with-an-attribution-id","heading":"Sandboxed commands are tagged with an attribution id","tier":"internal","area":"Sandbox","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224\/e\/sandboxed-commands-are-tagged-with-an-attribution-id","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224","markdown":"### Sandboxed commands are tagged with an attribution id\n\nSandboxed commands now carry an id into the sandbox config so activity traces back to its command.\n\n**What**\n\nCommands run in the sandbox now pass an identifier through to the sandbox wrapper, where it appears as a command id in the macOS and Linux sandbox configuration, so sandbox activity can be traced back to the command that caused it.\n\n**Details**\n\n- A new sandbox attribution id option is threaded through the bash and PowerShell exec path into both sandbox wrapper entry points.\n- The macOS sandbox log watcher was reworked to decode its command marker through a caller-supplied resolver, defaulting to identity, instead of a pre-built ignore map.\n\n**Evidence**\n\n`sandboxAttributionId`\n\n- Area: Sandbox\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}