Use --add-dir to Give Claude Access to Files Outside Your Current Directory
By default, Claude Code scopes itself to your current working directory. But real projects don't always live in one folder — you might need to reference a shared library, check an API contract from another service, or work across packages in a monorepo.
# Add a sibling package so Claude can see both
claude --add-dir ../shared-components
# Add multiple directories at once
claude --add-dir ../api-contracts --add-dir ../design-tokens
# Add a completely separate project for cross-referencing
claude --add-dir ~/Code/company-sdk
Now Claude can read files from those directories, search across them, and understand how your code relates to the external codebase. It won't write to those directories by default — it treats them as read context — but it can reference types, contracts, and patterns from them.
This is especially powerful for monorepo workflows:
# Working on the frontend, but need Claude to understand the API
cd packages/web-app
claude --add-dir ../api --add-dir ../shared-types
Claude can now see your API route definitions and shared TypeScript types while working on the frontend — so it generates code that actually matches the backend contracts instead of guessing.
A few practical use cases:
- Monorepos — reference sibling packages without changing directories
- API integration — point at the API project so Claude matches real endpoints and response shapes
- Shared libraries — let Claude see the utility library your project imports
- Migration projects — show Claude both the old and new codebases side by side
When your code depends on files outside your directory, --add-dir brings them into Claude's world.
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.