feat: /add-dir command

[Leka74]

What does this PR do?

Adds a /add-dir command, which gives the agent permissions to that directory in the existing session.

How did you verify your code works?

Tested locally.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found one potentially related PR:

Related PR:

• PR feat: Permissions dialog #8859 - "feat: Permissions dialog" (feat: Permissions dialog #8859)

This PR is closely related since PR #8943 adds a /add-dir command to grant the agent permissions to a directory. The permissions dialog PR would be directly related to how those permissions are handled and presented to the user.

The other PRs that appeared in results (#7378, #6714, #5841, #7515) are related to directory permissions but don't appear to be duplicates—they address different aspects like the --dir flag, external directory checks, and permission configuration rather than the /add-dir command itself.

[rekram1-node]

This is actually pretty clean dang, ig let's fix typechecks and tests and should be mostly good.

[rekram1-node]

Wonder if we should inject something into context tho about the dir, like running the ls against it and sending as a user message that doesnt trigger generation (using noReply)

[Leka74]

Thought about that. Could add it in.

[rekram1-node]

Feel like we should yeah

[Leka74]

Wonder if we should inject something into context tho about the dir, like running the ls against it and sending as a user message that doesnt trigger generation (using noReply)

how do you feel about re-using ListTool for this? It has all the formatting etc. but the only downside is it needs a sort of a dummy ctx created for it. Or we just use ripgrep in it directly.

const ctx = {
  sessionID: body.sessionID,
  messageID: "",
  agent: "",
  abort: new AbortController().signal,
  extra: { bypassCwdCheck: true },
  metadata: () => {},
  ask: async () => {},
}
const result = await ListTool.init().then((t) => t.execute({ path: resolved }, ctx))

await SessionPrompt.prompt({
  sessionID: body.sessionID,
  noReply: true,
  parts: [{ type: "text", text: `Added directory to context:\n\n${result.output}` }],
})

EDIT: Probably an anti-pattern tbh, I think just using ripgrep is fine.

[Leka74]

Wonder if we should inject something into context tho about the dir, like running the ls against it and sending as a user message that doesnt trigger generation (using noReply)

Added this. The only blocker now is the Type instantiation is excessively deep and possibly infinite., which will have to get fixed via another pr or we could split it into a diff route now and not wait for that.

[rekram1-node]

Merged ur other pr in basically

[Leka74]

Merged ur other pr in basically

Should be good to merge, resolved merge conflict.

[rekram1-node]

I think this one is basically good, going to tweak the prompting of it a bit and prolly make the endpoint experimental (but we will keep it hooked up, may change routing / structure in future)