/add-dir

Let this session read and edit an additional directory

What it does

A session is scoped to the directory it started in. /add-dir widens that scope so the agent can work in another directory too — a sibling repository, a shared schema folder, generated types living outside the project.

/add-dir ../shared-protos
/add-dir /Users/me/work/other-service
/add-dir                        show what's currently allowed
/add-dir status                 same

Arguments

Form	Effect
`/add-dir <path>`	allow that directory for this session
`/add-dir` or `/add-dir status`	list the additional directories currently allowed

Relative paths resolve against the session's working directory, so ../shared-protos does what you'd expect. Absolute paths are used as given.

Responses you might see

Message	Meaning
`Added working directory for this session: <path>`	done
`Directory not found: <path>`	the path doesn't exist or isn't a directory — nothing changed
`Directory already allowed for this session: <path>`	no-op, already in scope
`No additional working directories are allowed for this session.`	nothing added yet

Scope and lifetime

The grant is per session. Starting a new session starts from the original directory only — it does not carry over, and it does not change any global configuration.

That's deliberate: widening filesystem access is exactly the kind of thing that should expire rather than accumulate silently across sessions.

Note

For a directory you always need, prefer a project-level configuration or a reference alias over running /add-dir in every session.

When you need it

Signs the agent is scope-limited rather than confused:

it says it can't find a file you know exists
the file is above the session's directory, or in a parallel checkout
you're working across two repositories at once