Describe the feature or problem you'd like to solve
Workspace .mcp.json config is only honored once a workspace has been marked "trusted," and the only way to grant that trust today is by starting an interactive session and answering "Yes" to the trust prompt. There is currently no way to trust a workspace from a non-interactive (-p) session, a scripted/CI environment, or any headless context. This was confirmed by a maintainer on #4542: workspace .mcp.json loading was fixed in 1.0.85, but only takes effect if the workspace is already trusted, and there's no CLI-only way to establish that trust. This makes committed, repo-scoped .mcp.json files effectively unusable in automated or headless workflows (CI pipelines, containers, scripted invocations) even though the underlying loading bug is fixed, because there's no non-interactive path to the trust step.
Proposed solution
Add a flag (e.g. --temporarily-trust-workspace, name open to maintainer preference) that grants the current working directory workspace trust for the duration of that single invocation, without requiring the interactive TUI trust prompt.
This would let users and CI systems opt into trusting a specific workspace explicitly and auditably per-invocation, rather than requiring either a persisted trust decision made interactively beforehand, or the --additional-mcp-config workaround that duplicates the already-committed .mcp.json.
Benefits:
- Unblocks CI/automation and headless use of workspace-scoped .mcp.json
- Avoids requiring users to persist trust ahead of time via the interactive flow
- Avoids the --additional-mcp-config duplication workaround
- Keeps trust explicit and scoped to one invocation, rather than silently trusting all workspaces
Example prompts or workflows
-
CI pipeline step: copilot --temporarily-trust-workspace --allow-all-tools -p "Run the test suite and summarize failures" — using the repo's committed .mcp.json without a prior interactive trust step.
-
Docker/headless container: running scripted copilot -p "..." invocations where no TTY is available to answer the interactive trust prompt.
-
One-off automation script that clones a repo, trusts it for a single non-interactive Copilot invocation, and never persists that trust decision to the user's config.
Additional context
#4542
Describe the feature or problem you'd like to solve
Workspace .mcp.json config is only honored once a workspace has been marked "trusted," and the only way to grant that trust today is by starting an interactive session and answering "Yes" to the trust prompt. There is currently no way to trust a workspace from a non-interactive (-p) session, a scripted/CI environment, or any headless context. This was confirmed by a maintainer on #4542: workspace .mcp.json loading was fixed in 1.0.85, but only takes effect if the workspace is already trusted, and there's no CLI-only way to establish that trust. This makes committed, repo-scoped .mcp.json files effectively unusable in automated or headless workflows (CI pipelines, containers, scripted invocations) even though the underlying loading bug is fixed, because there's no non-interactive path to the trust step.
Proposed solution
Add a flag (e.g. --temporarily-trust-workspace, name open to maintainer preference) that grants the current working directory workspace trust for the duration of that single invocation, without requiring the interactive TUI trust prompt.
This would let users and CI systems opt into trusting a specific workspace explicitly and auditably per-invocation, rather than requiring either a persisted trust decision made interactively beforehand, or the --additional-mcp-config workaround that duplicates the already-committed .mcp.json.
Benefits:
Example prompts or workflows
CI pipeline step:
copilot --temporarily-trust-workspace --allow-all-tools -p "Run the test suite and summarize failures"— using the repo's committed .mcp.json without a prior interactive trust step.Docker/headless container: running scripted
copilot -p "..."invocations where no TTY is available to answer the interactive trust prompt.One-off automation script that clones a repo, trusts it for a single non-interactive Copilot invocation, and never persists that trust decision to the user's config.
Additional context
#4542