{"version":"2.1.290","anchor":"bash-permission-redirection-stripped-allow-no-longer-silent","canonical_anchor":"bash-permission-redirection-stripped-allow-no-longer-silent","heading":"Allow rules no longer approve shell commands that redirect output elsewhere","tier":"notice","area":"Permissions","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/bash-permission-redirection-stripped-allow-no-longer-silent","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### Allow rules no longer approve shell commands that redirect output elsewhere\n\nA command allowed only once its output redirection is removed is now rechecked as written, and refused if the full form is not allowed\n\n**Unclear.** It is unclear whether the redirection recheck always applies or depends on a switch that could not be identified.\n\n**What**\n\nPermission rules let you allow shell commands so Claude can run them without asking. Output redirection is the part of a command, such as `> file.txt`, that sends its output into a file. Before, a command could be allowed because a rule matched it with the redirection removed. Claude Code now rechecks the command with its redirection included. If that full form is not allowed, the command is not approved, and the reason given is \"Allowed by a permission rule only with its output redirection removed; not allowed as written\".\n\nThe check that decides whether a `ps` command only reads information was also tightened. It now treats `--forest` and several combinations of options differently.\n\n**Why**\n\nAn allow rule meant for a harmless command could previously approve that same command writing to a file through redirection. Commands like that now go through the normal permission prompt.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: yes"}