[FEATURE] Let worktree.symlinkDirectories link tracked files (live data), not just directories

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

.worktreeinclude and worktree.symlinkDirectories don't cover tracked files that are live data, not code.

Setup: a personal-assistant repo where the same branch holds both scripts and append-only records: a daily log, a journal directory, an inbox file, a principles/rules doc, a patterns directory. These files are tracked in git (they are the point of the repo), but they change many times a day from the main checkout and are only committed once a night.

What breaks: the desktop app gives every session its own worktree, i.e. a snapshot of the branch tip. So each morning session

• reads yesterday's data as of the last commit, not as it is now;
• writes new entries into the worktree copy, which then diverges from the main checkout;
• produces links like daily-journal/<date>.md that open a stale copy, or nothing at all if the file was created after the branch point.

Why the existing knobs don't fit:

• .worktreeinclude only copies files that are gitignored, so tracked files are excluded by design (same restriction as #62445 / #71913). Copying is also the wrong primitive here: a copy is stale the moment the main checkout appends a line.
• worktree.symlinkDirectories is the right primitive (a link back to the main checkout), but it takes directories only, relative to the repo root. Live data here includes single files (daily_log.md, inbox.md) and two directories that live outside the repo. Whether a tracked directory gets replaced by the link is also undocumented.
• WorktreeCreate replaces worktree creation entirely, which is a lot of machinery to swap for "link these nine paths".

Proposed Solution

Either of these would remove the need for a custom hook:

1. Let worktree.symlinkDirectories accept files as well as directories, and document that a tracked path is replaced by the link (checked-out copy removed, symlink to the main checkout put in its place).
2. Or give .worktreeinclude a "link instead of copy" mode that also accepts tracked paths.

Option 1 seems the smaller change since the link primitive already exists.

Alternative Solutions

Current workaround: a .worktree-live list file in the repo root plus a git post-checkout hook (shared via core.hooksPath) that, for each listed path in a freshly created worktree, removes the checked-out copy and symlinks it to the main checkout. It works, but it lives outside Claude Code's knowledge of the worktree and silently no-ops on any machine where the hook path isn't configured.

Other options considered: committing live data more often (defeats the once-a-night archive), moving live data out of the repo (loses history), or disabling per-session worktrees in the desktop app (loses isolation for the code side).

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. Repo has daily_log.md (tracked) and daily-journal/ (tracked); both are appended to daily from the main checkout and committed nightly.
2. With "worktree": { "symlinkDirectories": ["daily_log.md", "daily-journal"] } (files allowed), every new desktop-app session's worktree would read and write the live files directly.
3. A session's reply link daily-journal/2026-09-06.md then opens today's real file instead of a stale or missing worktree copy.

Additional Context

• Related closed issues: #62445 and #71913 ask to drop the gitignored-only restriction on .worktreeinclude; both were auto-closed for inactivity. This request is narrower and targets the link primitive rather than copy.
• Happy to share the post-checkout hook script as a reference for the semantics.