{"version":"2.1.310","anchor":"read-file-adds-a-link-text-climbs-refusal-and-project-doc-re","canonical_anchor":"read-file-adds-a-link-text-climbs-refusal-and-project-doc-re","heading":"Reading artifact files now refuses symlinks that climb up folders partway through","tier":"notice","area":"Artifacts","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310\/e\/read-file-adds-a-link-text-climbs-refusal-and-project-doc-re","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310","markdown":"### Reading artifact files now refuses symlinks that climb up folders partway through\n\n`read_file` now refuses a path through a symlink whose target goes up a folder after its leading \"..\/\" parts\n\n**What**\n\n`read_file` now refuses a path that passes through a symlink (a shortcut file that points to another location) when the symlink's target uses \"..\" (go up one folder) anywhere after its leading \"..\/\" parts. A target that only climbs at the start is still accepted; one that climbs again further along is rejected.\n\nSeparately, a new kind of attachment, `project_doc_reads`, now sits in the same group as `inlined_image_paths`, `mcp_resource` and `structured_output`. An attachment is an extra piece of context Claude Code adds to the conversation.\n\n**Why**\n\nThe refusal closes off a way for a file path to reach outside where it is meant to through a crafted symlink. The new attachment type points toward reads of project documents being handled as their own kind of context.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}