{"version":"2.1.301","anchor":"backgrounded-bash-results-validate-output-path-and-sanitize","canonical_anchor":"backgrounded-bash-results-validate-output-path-and-sanitize","heading":"Background shell command results are checked before Claude sees them","tier":"internal","area":"Background Shells","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.301\/e\/backgrounded-bash-results-validate-output-path-and-sanitize","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.301","markdown":"### Background shell command results are checked before Claude sees them\n\nClaude Code now checks the task ID, output file path and folder note on a background shell command's result, and drops or rewrites any that look wrong\n\n**What**\n\nClaude can run a shell command in the background, meaning the command keeps running while Claude carries on with other work. Its output is saved to a file. When Claude Code reports such a command back to Claude, the report can include three extra details: the task's ID, the path of its output file, and a note about the working folder (the directory the command runs in).\n\nClaude Code now keeps the task ID and output path only when both of these are true:\n\n- The ID belongs to a background shell task that Claude Code actually started.\n\n- The output path is a plain, complete path of at most 4096 characters, with no `.` or `..` parts, ending in `\/<taskId>.output`.\n\nThe working folder note is rewritten into a fixed wording. If it does not match the expected form, a generic message replaces it. That message says, among other things, that folder changes made by the background command do not carry over to later commands.\n\n**Why**\n\nThese details end up in text Claude reads. Checking them stops a forged file path or a misleading folder note from being slipped into Claude's view of a background command.\n\n- Area: Background Shells\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}