Custom agent invoked as subagent cannot write files despite edit tool and Allow All permissions

## Type

Bug

## Summary

A workspace custom agent invoked as a subagent from another custom agent is unable to modify files, even though:

- the custom agent declares an editing tool;
- the runtime exposes a write-capable tool (`apply_patch`);
- the workspace is readable and correctly detected;
- the parent session permission level is set to `Allow All`;
- the user explicitly authorizes workspace modifications.

The subagent is therefore unable to persist artifacts or working memory when invoked by a coordinating custom agent.

This appears related to #304574, although that issue involved Copilot CLI running as a third-party agent inside VS Code. This reproduction uses custom agents in the VS Code Agents window with the Copilot harness.

## Environment

- OS: macOS
- Workspace: local filesystem
- Feature: VS Code Agents window
- Harness: Copilot
- Custom agents defined under `.github/agents/`
- Permission levels tested:
- Manual permissions
- Allow All
- Model: GPT-5.6 Terra
- VS Code version: ``
- VS Code commit/build: ``

## VS Code Versions

```text
Version: 1.137.0 (Universal)
Commit: 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
Date: 2026-09-08T13:43:59-07:00
Electron: 42.10.0
ElectronBuildId: 15109253
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.84.70.gdb75d0d
@github/copilot-sdk: 1.0.13-preview.4
OS: Darwin arm64 25.6.0
```

## Custom agent configuration

Example custom agent:

```yaml
---
name: Architect
description: Translates confirmed domain decisions and requirements into software architecture and technical design.
user-invocable: false
model: GPT-5.6 Terra
agents: []

tools:
- search/codebase
- search/usages
- read
- edit
---
```

The coordinating custom agent allows `Architect` as a subagent:

```yaml
---
name: Project Manager
user-invocable: true
model: GPT-5.6 Terra

tools:
- agent

agents:
- Domain Expert
- Architect
---
```

## Steps to reproduce

1. Open a local workspace in the VS Code Agents window.

2. Define a custom agent under `.github/agents/` with read and edit capabilities, for example the `Architect` agent above.

3. Define another custom agent that can invoke `Architect` through the `agent` tool.

4. Start a session using the coordinating agent.

5. Ask the coordinator to invoke `Architect` with a minimal write test, for example:

> Create `.agent-state/architect/precondition-write-test.md`, read it back, modify it, and read it again.

6. Observe that the `Architect` subagent can read the workspace but does not perform the write.

7. Set the parent session permission level to `Allow All`.

8. Repeat the same write test.

9. Observe that the subagent is still unable to write.

## Observed behavior

The subagent successfully detects and reads the workspace.

In one reproduction, the subagent explicitly reported that its effective tools included:

- workspace reading via `view`;
- modification via `apply_patch`.

However, it also reported that the effective policy of the invocation prevented it from writing files.

Example report from the subagent:

> Effective tools available: workspace reading (`view`) and modification via patch (`apply_patch`), but the effective policy of this invocation forbids file writes.

The subagent correctly identified:

- working directory:
`/Users//Projects/eventatlas`
- intended write path:
`/Users//Projects/eventatlas/.agent-state/architect/precondition-write-test.md`

but did not execute the write.

The user then explicitly authorized arbitrary workspace modifications in the prompt.

The result did not change.

The parent session was then changed from `Manual permissions` to `Allow All`.

The result still did not change.

No file was created or modified.

## Expected behavior

When a custom agent declares editing capabilities such as:

```yaml
tools:
- read
- edit
```

and is invoked as a subagent, it should be able to use those capabilities subject to the normal VS Code permission model.

If the parent session is configured with `Allow All`, a write-capable custom subagent should be able to create and edit files inside the workspace.

A custom agent used as a subagent should retain the model, tools, and instructions configured in its custom agent definition.

## Actual behavior

The custom subagent:

- can read workspace files;
- can report a write-capable runtime tool such as `apply_patch`;
- nevertheless behaves as if an invocation-level read-only policy prevents use of that tool;
- remains unable to write even when the parent session permission level is `Allow All`;
- remains unable to write even when the user explicitly authorizes workspace modifications in the prompt.

## Why this matters

This prevents coordinator/custom-agent workflows where specialist subagents need to produce persistent outputs.

Examples include:

- an Architect writing architecture documentation;
- an Architect creating or updating ADRs;
- a Domain Expert persisting domain documentation;
- specialist agents maintaining local working memory between stateless invocations;
- an Implementer modifying source code;
- a QA agent creating or updating test artifacts.

In a coordinator pattern such as:

```text
User
↓
Project Manager
├── Domain Expert
├── Architect
├── Implementer
└── QA
```

specialists can analyze the workspace but cannot reliably persist their results when invoked as subagents.

This forces the coordinator to either:

- perform writes on behalf of specialists;
- create additional ad-hoc agents;
- or keep specialist results only in chat.

All of those significantly reduce the usefulness of custom subagents for multi-agent software-development workflows.

## Additional observations

The issue does not appear to be caused by the natural-language instructions given to the agent.

Explicitly telling the subagent that it may modify any file in the workspace does not change the result.

It also does not appear to be caused solely by the normal approval mode.

The behavior is reproduced with both:

- `Manual permissions`
- `Allow All`

The runtime appears to know about a write-capable operation (`apply_patch`), but an effective policy associated with the subagent invocation prevents the operation from being used.

This suggests the restriction may be applied at the subagent invocation/runtime-policy level rather than at the custom agent tool-definition or normal approval level.

## Possible related issue

Possibly related:

- #304574

That issue described custom agents invoked as subagents receiving an effectively read-only tool environment in another VS Code-hosted agent scenario.

The current reproduction differs because:

- it uses the VS Code Agents window;
- it uses the Copilot harness;
- it uses workspace custom agents under `.github/agents/`;
- the subagent can report a write-capable tool such as `apply_patch`;
- the behavior persists with `Allow All`.

## Minimal expected test

A minimal custom subagent with editing enabled should be able to perform:

```text
create file
↓
read file
↓
modify file
↓
read modified file
```

For example:

```text
.agent-state/architect/precondition-write-test.md
```

Currently the flow stops before the initial write when the custom agent is invoked as a subagent.