Use --add-dir to Give Claude Access to Files Outside Your Project
Claude Code normally only sees files in your current working directory. But real projects often depend on context that lives elsewhere — a shared component library, a sibling microservice, or documentation in a separate repo.
claude --add-dir ../shared-lib
Now Claude can read files from both your project and the shared library. It sees the full picture when making changes that cross boundaries.
You can add multiple directories:
claude --add-dir ../api-service --add-dir ../shared-types --add-dir ~/docs/architecture
This is invaluable for:
# Working on a frontend that calls a sibling API
claude --add-dir ../backend-api \
-p "update the user profile form to match the new API response shape"
# Referencing shared types across packages in a monorepo
claude --add-dir packages/shared \
-p "add the new PaymentStatus enum to the order service"
# Including design docs for context
claude --add-dir ../design-docs \
-p "implement the checkout flow described in the spec"
Claude treats added directories as read context — it can read and search files there, but won't modify them unless you explicitly ask. This makes it safe to include reference material without worrying about unintended edits.
A few things to know:
- Added directories appear alongside your project files in Claude's view
- Claude can grep, glob, and read from them just like local files
- Great for monorepos where packages reference each other
- Works with both interactive sessions and
-pone-shot mode
Your project doesn't exist in isolation — --add-dir gives Claude the same cross-repo context you have.
via Claude Code
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.