A permitting modernization effort keeps the intake web application and the fee-calculation service in two separate repositories. An architect working in the intake repository needs Claude Code to read the fee service's source while implementing a new plan-review fee, without moving or copying either repository. What is the appropriate way to do this?

A session's file access is scoped to the directory it was started in, which is a sensible default boundary and an awkward one for the very common multi-repository case. The right response is to widen that boundary deliberately for the second repository, not to defeat it wholesale or to smuggle file contents across it by hand.

--add-dir names an additional workspace directory at session start, so the architect working in the permitting intake repository can read the fee-calculation service's source while both repositories keep their own location, history, and tooling. The grant is explicit and visible on the command line, which is what distinguishes widening a boundary from removing one.

A symbolic link is a filesystem trick that muddies the working tree and risks the second repository's files being treated as part of the first, including by git operations; pasting the relevant files by hand is manual, goes stale the moment either repository changes, and does not scale past a couple of files; and skipping permissions is both far broader than needed and aimed at the wrong control, since it disables prompting generally rather than granting access to one specific additional directory.

Exam caveat: an added directory is in scope for the whole session, so write-capable tools reach it too and read-only intent is not enforced by the flag itself. Operational check: start the session with --add-dir, confirm a read of a fee-service file succeeds, and if the work is meant to be read-only, pair the flag with permission rules denying writes outside the intake repository.