Feature request: tool-callable cwd
Summary
/cwd <path> already exists as a TUI command, and as a side effect it triggers a skill rescan so any .github/skills/ under the new directory are picked up without restarting. It works great for users, but it can't be invoked by skills or the agent — there's no equivalent tool. This means workflows that change context mid-session (e.g., a skill that switches into a repo) can't programmatically move the session into the right directory or pick up the new repo's skills. The user has to remember to type the command.
Please expose /cwd as a tool-callable operation so skills and agents can change the session's working directory after they've decided where work should happen.
Repro
- From
~, launch copilot.
- A skill (or the user) decides work should happen in a different directory — for example,
Azure/azure-sdk-for-net, which ships ~10 skills under .github/skills/ (pre-commit-checks, mgmt-review-comment-resolution, etc.).
- The skill has no way to move the session there. Its powershell tool
Set-Location only changes the child-process cwd; copilot's own cwd stays at ~. There's no tool to invoke /cwd either.
Expected: A tool the skill can call to change the session's working directory (matching /cwd <path> semantics, including the skill rescan side effect).
Actual: Skill must instruct the user to type the command themselves.
Why this matters
If you work across many repos regularly, the natural workflow is to launch copilot once from your home directory and just say "we need to work on issue <link>" — letting the agent figure out which repo the issue belongs to, where its clone lives on disk, claim a free copy, branch, and start. Forcing the user to cd into the right repo before launching defeats this entirely (you'd have to know which repo every time, manually navigate there, and start a fresh session per repo).
A common pattern: launch copilot from a stable home dir and let an agent/skill route work to the right repo (e.g., we maintain a repo-finder skill that resolves an issue link → repo, scans C:\git\ for a free clone, claims it, creates a branch, and starts work). Today, repo-level skills like pre-commit-checks silently don't run because they were never registered for this session, and the user has to know to manually run /cwd <path> before the agent does anything that depends on the missing skill.
There's no way for the skill to detect-and-fix this from inside the session.
Proposed shape
cwd() # returns current cwd (matches `/cwd` with no args)
cwd(path: "...") # change cwd to path; triggers skill rescan as today
Treated like other state-changing tools for permissions: agent must request approval the first time, persistent thereafter.
With this, our repo-finder skill could simply call cwd(path) after picking the repo and the user wouldn't need to do anything.
Environment
- copilot CLI: 1.0.40-0
- OS: Windows 11
Feature request: tool-callable
cwdSummary
/cwd <path>already exists as a TUI command, and as a side effect it triggers a skill rescan so any.github/skills/under the new directory are picked up without restarting. It works great for users, but it can't be invoked by skills or the agent — there's no equivalent tool. This means workflows that change context mid-session (e.g., a skill that switches into a repo) can't programmatically move the session into the right directory or pick up the new repo's skills. The user has to remember to type the command.Please expose
/cwdas a tool-callable operation so skills and agents can change the session's working directory after they've decided where work should happen.Repro
~, launchcopilot.Azure/azure-sdk-for-net, which ships ~10 skills under.github/skills/(pre-commit-checks,mgmt-review-comment-resolution, etc.).Set-Locationonly changes the child-process cwd; copilot's own cwd stays at~. There's no tool to invoke/cwdeither.Expected: A tool the skill can call to change the session's working directory (matching
/cwd <path>semantics, including the skill rescan side effect).Actual: Skill must instruct the user to type the command themselves.
Why this matters
If you work across many repos regularly, the natural workflow is to launch
copilotonce from your home directory and just say "we need to work on issue <link>" — letting the agent figure out which repo the issue belongs to, where its clone lives on disk, claim a free copy, branch, and start. Forcing the user tocdinto the right repo before launching defeats this entirely (you'd have to know which repo every time, manually navigate there, and start a fresh session per repo).A common pattern: launch
copilotfrom a stable home dir and let an agent/skill route work to the right repo (e.g., we maintain arepo-finderskill that resolves an issue link → repo, scansC:\git\for a free clone, claims it, creates a branch, and starts work). Today, repo-level skills likepre-commit-checkssilently don't run because they were never registered for this session, and the user has to know to manually run/cwd <path>before the agent does anything that depends on the missing skill.There's no way for the skill to detect-and-fix this from inside the session.
Proposed shape
Treated like other state-changing tools for permissions: agent must request approval the first time, persistent thereafter.
With this, our
repo-finderskill could simply callcwd(path)after picking the repo and the user wouldn't need to do anything.Environment