Problem
Repository-provided hook configuration can become a supply-chain execution surface when a repository is compromised.
SafeDep recently documented the Miasma worm campaign, where malicious commits added project configuration for multiple developer tools and used auto-run hook/task mechanisms to execute a payload when a developer opened or started an AI coding agent in the repository:
https://safedep.io/miasma-worm-ai-coding-agent-config-injection/
The relevant pattern is that the attacker did not need to compromise the agent binary. They only needed to land repository configuration such as .claude/settings.json / .gemini/settings.json hooks, editor tasks, or agent instructions that cause local code execution. A similar class of risk exists for any agent that automatically trusts repository-provided hook configuration.
Request
Please add a first-class way for users and automation to disable repository/workspace hooks in Copilot CLI.
Examples of possible UX:
copilot --disable-hooks
copilot --disable-repository-hooks
copilot --no-hooks
or an environment/configuration option such as:
COPILOT_DISABLE_HOOKS=1
COPILOT_DISABLE_REPOSITORY_HOOKS=1
The important property is that users and CI systems should be able to start Copilot CLI in a mode where hooks from the checked-out repository are not loaded or executed.
Why this matters
Hooks are useful for policy enforcement and local automation, but repository-controlled hooks can also be abused as a persistence/execution mechanism after a source repository compromise. In the Miasma case, the attacker used developer-tool configuration injection to run a payload on clone/open/session start.
A user may want to inspect or remediate an untrusted repository with Copilot CLI without allowing that repository to execute hook code first.
This is especially important for:
- Incident response on potentially compromised repositories
- Reviewing third-party or newly cloned repositories
- CI or automation that runs Copilot CLI on untrusted branches/forks
- Enterprise environments that want hooks only from trusted user/org policy, not from arbitrary repo contents
Prior art
Other AI coding tools have options to suppress or disable hooks / project-provided automation. Copilot CLI should provide an equivalent safety switch so users can opt out of repository hooks when the repository is not yet trusted.
Desired behavior
When the option is set:
- Repository/workspace hooks should not be loaded or executed.
- The CLI should clearly log or display that repository hooks were disabled by user choice.
- Ideally, trusted user-level or enterprise-managed hooks could still be allowed separately, if that distinction exists in the hook loader.
Related context
There are existing hook-related issues where missing hook enforcement is treated as a security problem, for example hooks not loading in some modes or subagents bypassing hooks. This request is the complementary control: users also need a deliberate, explicit way to not trust repository-provided hooks when working with untrusted code.
Problem
Repository-provided hook configuration can become a supply-chain execution surface when a repository is compromised.
SafeDep recently documented the Miasma worm campaign, where malicious commits added project configuration for multiple developer tools and used auto-run hook/task mechanisms to execute a payload when a developer opened or started an AI coding agent in the repository:
https://safedep.io/miasma-worm-ai-coding-agent-config-injection/
The relevant pattern is that the attacker did not need to compromise the agent binary. They only needed to land repository configuration such as
.claude/settings.json/.gemini/settings.jsonhooks, editor tasks, or agent instructions that cause local code execution. A similar class of risk exists for any agent that automatically trusts repository-provided hook configuration.Request
Please add a first-class way for users and automation to disable repository/workspace hooks in Copilot CLI.
Examples of possible UX:
or an environment/configuration option such as:
The important property is that users and CI systems should be able to start Copilot CLI in a mode where hooks from the checked-out repository are not loaded or executed.
Why this matters
Hooks are useful for policy enforcement and local automation, but repository-controlled hooks can also be abused as a persistence/execution mechanism after a source repository compromise. In the Miasma case, the attacker used developer-tool configuration injection to run a payload on clone/open/session start.
A user may want to inspect or remediate an untrusted repository with Copilot CLI without allowing that repository to execute hook code first.
This is especially important for:
Prior art
Other AI coding tools have options to suppress or disable hooks / project-provided automation. Copilot CLI should provide an equivalent safety switch so users can opt out of repository hooks when the repository is not yet trusted.
Desired behavior
When the option is set:
Related context
There are existing hook-related issues where missing hook enforcement is treated as a security problem, for example hooks not loading in some modes or subagents bypassing hooks. This request is the complementary control: users also need a deliberate, explicit way to not trust repository-provided hooks when working with untrusted code.