Run on folder open is a task setting that starts configured automation when a project is opened in the editor. It is useful for developer productivity, but in attacker-controlled repositories it becomes an execution trigger that can launch shell commands before meaningful review occurs.
What Run on Folder Open Means in Practice
Run on folder open is a productivity feature, but it also changes the trust model of a repository. The moment an editor opens the project, automation can execute before a person has reviewed the files, so the setting deserves the same caution you would give any implicit execution path.
The key idea is that “open” becomes an event with security meaning, not just a navigation action. In a trusted project, that can save setup time. In an untrusted one, it can turn a routine browsing action into code execution without an explicit launch.
How the Trigger Works
Most implementations bind the behavior to workspace or project metadata, then allow configured tasks, scripts, or commands to start when the folder is loaded. That makes the feature useful for build steps, environment preparation, or developer onboarding, but it also means the execution boundary sits earlier in the workflow than many users expect.
Because the trigger is tied to project opening rather than a deliberate run command, the practical risk is not just “automated convenience.” It is the possibility that repository content can steer local execution through editor-integrated behavior, especially when users open cloned code from unfamiliar sources.
Security Implications and Trust Boundary
Run on folder open is best understood as a trust-boundary shortcut. It assumes the folder contents, editor settings, and configured automation are legitimate, so any weakness in repository trust or review discipline can turn that shortcut into an execution primitive.
That matters because the feature can bypass the normal pause that gives people time to inspect scripts, task definitions, and workspace configuration. The earlier the automation fires, the less opportunity there is to notice that a repository is asking for action rather than merely presenting code.
For that reason, the setting sits close to broader supply-chain and repository-trust concerns, especially when combined with other automatic behaviors such as task runners, build hooks, or environment bootstrapping. Guidance from OpenSSF is useful here because it frames open-source consumption as a security and trust problem, not only a development convenience.
Safer Use in Development Environments
In trusted internal projects, the feature can be appropriate when teams need repeatable setup and the repository is governed well. In shared or external code, the safer default is to treat folder-open execution as a high-risk convenience and reserve it for environments where the source, reviewers, and automation are already controlled.
Practically, this means the setting should be enabled only when the team can explain what executes, why it executes, and who approved it. The same caution applies to any editor-integrated automation that runs before the user has consciously chosen to launch it. NIST control guidance on configuration management and system integrity, such as NIST SP 800-53 Rev 5 Security and Privacy Controls, is a good fit for thinking about those defaults.
Risk and Threat Considerations
Run on folder open is risky because attacker-controlled repositories can turn a normal preview step into an execution event. The danger is not just accidental misconfiguration, but deliberate abuse of trust in project metadata and editor automation.
Failure mechanism: A malicious repository places commands or task definitions in files that the editor honors on open, causing code or shell activity to start before the user has meaningfully reviewed the project.
Impact: This can lead to unwanted local execution, credential exposure, environment modification, or a foothold for follow-on activity if the workstation or development environment is overprivileged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Run-on-open automation is a software trust and execution boundary issue. |
| Recommendation — Restrict editor-triggered automation to trusted repositories and review configuration that can execute code. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Disabling unnecessary auto-execution reduces unintended code launch on folder open. |
| CM-6 — Configuration Settings | Workspace-triggered execution depends on controlled configuration choices. | |
| SI-7 — Software, Firmware, and Information Integrity | The risk is malicious repository content causing integrity-impacting execution. | |
| Recommendation — Disable unnecessary folder-open automation and allow only approved startup behavior. Harden editor and workspace defaults so untrusted projects cannot auto-run tasks. Validate repository-supplied automation before allowing it to execute. | ||
| OWASP ASVS | V13 — Configuration | Workspace and editor settings are security-relevant configuration. |
| Recommendation — Review project configuration that can trigger code execution on open. | ||
| MITRE ATT&CK | T1204 — User Execution | The technique abuses a user action to trigger execution from untrusted content. |
| Recommendation — Detect when user-triggered opening of content leads to unexpected code execution. | ||
Practitioner Guidance
Why practitioners should care: Treat folder-open automation as an execution policy decision, not just a convenience toggle. If teams do not define when it is allowed, users may enable it in contexts where repository trust is unknown or temporary.
Common misunderstanding: Many developers assume that opening a folder is passive. In reality, the editor may evaluate workspace configuration early enough that the distinction between “viewing code” and “running code” disappears.
Practitioner takeaway: The safest operational stance is to allow this behavior only in repos and environments where the automation is explicit, reviewed, and expected.
Related resources from NHI Mgmt Group
- What breaks when folder-open tasks are allowed to run in an untrusted code editor?
- How should security teams run user access reviews when a file platform has frequent role changes and granular folder permissions?
- What happens when a container is allowed to run shell scripts, spawn new processes, and open outbound network connections without runtime controls?
- What happens when teams run a gateway without a clear distinction between open source builds and the enterprise package?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org