{"version":"2.1.310","anchor":"file-inputs-reject-paths-that-resolve-elsewhere","canonical_anchor":"file-inputs-reject-paths-that-resolve-elsewhere","heading":"Files whose path leads somewhere else are refused when attached","tier":"notice","area":"File Reading","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310\/e\/file-inputs-reject-paths-that-resolve-elsewhere","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310","markdown":"### Files whose path leads somewhere else are refused when attached\n\nAttaching or reading a file whose path resolves to a different real path, such as through a link, is now refused with the reason resolves_elsewhere\n\n**What**\n\nSome paths do not point straight at a file. A link (symlink), or a stored name, can lead to a file somewhere else. Claude Code now checks for this when files are passed in or attached.\n\n- The file input reader has a new rejection reason, `resolves_elsewhere`. It applies when a path leads through a link to a different real path, unless the caller allows following links. Before, only the `path_rejected` and `name_direction` checks applied.\n\n- The credential check on file inputs also takes a new `fromChat` option.\n\n- The tool that attaches files refuses such a file with \"Cannot attach ... it resolves to another path\". The message asks Claude to try again using the resolved path.\n\n- When a file input is not attached for this reason, it is recorded as a normal outcome rather than an error. That is how `input_schema` was already handled.\n\n**Why**\n\nThe file that is sent is now the same file whose path was approved. If you pass a linked file, expect a refusal, and use the file's real path instead.\n\n- Area: File Reading\n- Names: `--file`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}