Inherit the initiating workspace scope for child agents

Start with the documented /spawn command and the GitHub Copilot app session setup documentation linked in the issue, then locate the child-agent launch and workspace configuration-discovery entry points. Trace how the child's CWD and launch metadata are established. Done means the listed acceptance criteria pass, including inherited or explicitly assigned CWD, ancestor-only configuration discovery, and troubleshooting visibility.

Feature summary

Automatically scope child agents to their target working directory

What problem are you trying to solve?

In a monorepo, an agent started in a service or app directory needs to use that directory as its real working scope. A child started from a repository-root task can otherwise run with a broader or different CWD and miss the scope-specific instructions, skills, and MCP configuration it needs. Asking it to cd in the prompt or granting extra path access is not equivalent to starting it in that scope.

Proposed solution

A child agent should inherit its parent session's actual CWD by default. When an orchestrator intentionally fans out across repository areas, it should be able to set each child's working directory through structured launch metadata. Initialize the child in that directory, then discover the applicable local and ancestor instructions, skills, and MCP configuration as if it had been started there directly. Preserve normal user/global configuration. Do not load unrelated sibling-specific configuration. This should require no prompt-level workaround, manual directory grant, or post-launch setup.

Workflow impact

This makes monorepo delegation predictable: a root-level end-to-end orchestrator can coordinate separately scoped service and app agents, while work begun inside an app or service stays in that scope when delegated.

Installation context

GitHub Copilot app sessions that use a local repository or workspace and spawn child agents.

Additional context

Illustrative directory structure

repository/
├── AGENTS.md
├── .mcp.json
├── .agents/
│   └── skills/
│       └── <root-skill>/SKILL.md
├── Api/
│   ├── AGENTS.md
│   ├── .mcp.json
│   └── .agents/skills/<api-skill>/SKILL.md
└── Apps/
    ├── AGENTS.md
    ├── .mcp.json
    ├── .agents/skills/<apps-shared-skill>/SKILL.md
    └── App/
        ├── AGENTS.md
        ├── .mcp.json
        └── .agents/skills/<app-skill>/SKILL.md

Expected scope and end-to-end example

A root orchestrator starts at repository/. It uses root-level configuration to coordinate an end-to-end workflow, then launches two children with actual working directories repository/Api/ and repository/Apps/App/.

• Api child (CWD=repository/Api/): load instructions from Api/AGENTS.md and repository/AGENTS.md; discover skills under Api/.agents/skills/ and repository/.agents/skills/; load workspace MCP configuration from Api/.mcp.json and repository/.mcp.json. Do not load Apps/-specific configuration.
• App child (CWD=repository/Apps/App/): load instructions from Apps/App/AGENTS.md, Apps/AGENTS.md, and repository/AGENTS.md; discover skills under Apps/App/.agents/skills/, Apps/.agents/skills/, and repository/.agents/skills/; load workspace MCP configuration from Apps/App/.mcp.json, Apps/.mcp.json, and repository/.mcp.json. Do not load Api/-specific configuration.
• Root orchestrator: remains at the repository root with root-level scope, receives both children's results, and combines them for the end-to-end outcome.

The key requirement is that the launcher's working-directory scope drives configuration discovery; mentioning a path in the prompt alone must not be treated as setting that scope. The app docs describe /spawn [PROMPT] but do not specify the child's CWD or configuration inheritance: https://docs.github.com/en/copilot/reference/github-copilot-app-reference/slash-commands. Session setup is documented separately: https://docs.github.com/en/copilot/how-tos/github-copilot-app/agent-sessions.

Acceptance criteria

• A child started from a scoped session inherits the parent's actual CWD by default.
• A parent orchestrator can assign a different child CWD through structured launch metadata for cross-area workflows.
• Each child automatically loads supported instructions, skills, and MCP configuration from its CWD and applicable ancestor directories, alongside normal user/global configuration.
• Scope-specific configuration from unrelated sibling directories is excluded.
• The root-orchestrator example above works without prompt-based cd, manual directory grants, or post-launch setup.
• The child CWD and discovered configuration scope can be verified during troubleshooting.