Summary
With a custom SessionFsProvider, Plan-mode path validation changes when only the session working directory changes. The same provider-owned Plan path succeeds when the session working directory matches the client InitialWorkingDirectory, but is rejected as outside the session folder when the session uses a different working directory.
The generated SessionFsSetProviderRequest contract says that initialCwd establishes the root of the provider's virtual namespace and that the provider is authoritative for path interpretation and workspace permission validation.
Versions
- GitHub.Copilot.SDK:
1.0.17-preview.7
- Bundled Copilot CLI:
1.0.93-1
- OS: Windows
- Target framework:
net10.0
Minimal standalone reproduction
Run:
The repro runs the same native create call twice. Both cases use:
InitialWorkingDirectory = {client-root}SessionStatePath = "session-state"- target
{client-root}\session-state\plan.md
- the same provider implementation and backing-store rules
The only changed value is the per-session working directory.
Expected
Both cases write the Plan through the provider and succeed without invoking the host permission callback.
Actual
| Session working directory |
Result |
Provider Plan writes |
Permission callbacks |
{client-root} |
success; SDK readback contains the Plan |
1 |
0 |
{workspace} |
denied; SDK Plan remains absent |
0 |
0 |
The denied result is:
`create` was blocked. Plan mode does not permit changes outside the session folder.
A scripted real agent turn produces the same result. When the directories differ, the native create and edit calls are denied before any SessionFs Plan operation or host permission callback. It also creates session-state\temp under the session working directory.
This is related to, but distinct from, #2698. The provider is already registered and authoritative; the failure is that the Plan guard changes anchors when the session working directory differs from initialCwd.
Summary
With a custom
SessionFsProvider, Plan-mode path validation changes when only the session working directory changes. The same provider-owned Plan path succeeds when the session working directory matches the clientInitialWorkingDirectory, but is rejected as outside the session folder when the session uses a different working directory.The generated
SessionFsSetProviderRequestcontract says thatinitialCwdestablishes the root of the provider's virtual namespace and that the provider is authoritative for path interpretation and workspace permission validation.Versions
1.0.17-preview.71.0.93-1net10.0Minimal standalone reproduction
Run:
The repro runs the same native
createcall twice. Both cases use:InitialWorkingDirectory = {client-root}SessionStatePath = "session-state"{client-root}\session-state\plan.mdThe only changed value is the per-session working directory.
Expected
Both cases write the Plan through the provider and succeed without invoking the host permission callback.
Actual
{client-root}success; SDK readback contains the Plan{workspace}denied; SDK Plan remains absentThe denied result is:
A scripted real agent turn produces the same result. When the directories differ, the native
createandeditcalls are denied before any SessionFs Plan operation or host permission callback. It also createssession-state\tempunder the session working directory.This is related to, but distinct from, #2698. The provider is already registered and authoritative; the failure is that the Plan guard changes anchors when the session working directory differs from
initialCwd.