Kiro runtime activity under C:\Users\<user>\.kiro triggers enterprise compliance issues

[rsstorey]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

Windows 11 Version 23H2 (OS Build 22631.7219)

Kiro Version

1.1.70 user setup

Bug Description

Kiro appears to create enterprise compliance issues on managed Windows development workstations because it uses user-profile storage and execution paths under C:\Users<user>.kiro... rather than clearly supporting a fully customer-controlled installation and runtime location. In my environment, development activity is required to remain within an approved and whitelisted path such as C:\dev, while user-profile locations remain subject to Carbon Black and other compliance controls. I observed endpoint-security activity tied to Kiro-managed content under the user profile, including Python execution from C:\Users<user>.kiro\extensions..., which resulted in Carbon Black flagging the activity as unapproved script execution from a user-writable path. This creates a deployment problem for enterprise and DoD-managed workstations because Kiro can trigger compliance violations even when the workstation is an approved development system, simply because Kiro-managed files and runtime activity do not appear to be fully relocatable to the approved development area. I need official clarification on whether this is a bug, a product limitation, or an unsupported enterprise deployment scenario, and whether Kiro can support a fully customer-controlled installation and runtime footprint under a designated path such as C:\dev.

Steps to Reproduce

Actual behavior

Kiro stores and executes user-level content from the default user-profile path under C:\Users<user>.kiro.... In my enterprise-managed Windows environment, that location remains subject to Carbon Black and other compliance controls rather than the approved and whitelisted development location under C:\dev. As a result, Kiro-managed extension and runtime activity under the user profile can be flagged as unapproved execution from a user-writable path. In my case, Carbon Black flagged Python execution from a Kiro-managed extension path under C:\Users<user>.kiro\extensions..., creating a compliance and deployment issue on an otherwise approved development workstation. This also restricts routine Kiro updating, because I cannot rely on a normal in-place update path under the managed user-profile location and instead must manually download and install the full Kiro package from my approved C:\dev area over the existing installation.

1. Use Kiro on an enterprise-managed Windows workstation where approved development activity must remain under a designated path such as C:\dev, while user-profile paths remain subject to endpoint security and compliance controls.
2. Install or launch Kiro in its normal supported/default configuration.
3. Allow Kiro to initialize its user-level data, extensions, and runtime-managed content under the default user-profile location, such as C:\Users<user>.kiro....
4. Use Kiro normally so that extensions and helper processes activate.
5. Observe endpoint-security activity for processes executing from Kiro-managed paths under the user profile.
6. In my case, Carbon Black flagged Python execution from a Kiro-managed extension path under C:\Users<user>.kiro\extensions..., identifying it as unapproved script execution from a user-writable location.
7. Compare this behavior to the enterprise requirement that development tooling and generated/runtime content be maintained in an approved and whitelisted development path such as C:\dev.

Expected Behavior

Expected behavior

Kiro should support a clearly documented enterprise deployment model that allows customers to keep all Kiro-managed user data, extensions, runtime files, update activity, and execution paths within an approved customer-controlled location such as C:\dev. Kiro should not require active use of user-profile storage and execution paths in environments where those locations are governed by endpoint-security and compliance controls. The product should support normal update and runtime behavior from the approved development location without requiring manual reinstallation workarounds. At minimum, the product should clearly document which Kiro-managed paths are required, which can be relocated, how update behavior works in managed environments, and whether a fully customer-controlled installation and runtime footprint is supported.

Conversation ID

No response

Additional Context

Ref: Feature Request Issue

kiro-session-sess_f65fe0c1-9a0b-4f96-9178-167a54a19b3c.zip

#11582

[github-actions]

Thanks for opening this issue and providing such a thorough description of the problem! This is a really important concern — we understand that Kiro's use of user-profile paths for storage and runtime activity can conflict with enterprise and DoD compliance requirements on managed workstations. A maintainer will take a look at this shortly to help clarify the path forward. We appreciate you bringing this to our attention, as feedback like this is invaluable for making Kiro work well in enterprise environments! 🙌

[AnilMaktala]

Thanks for the enterprise context. Carbon Black and similar EDR tools flagging Python execution under %USERPROFILE%\.kiro\extensions is a real enterprise deployment blocker -- making the extension runtime path relocatable via KIRO_HOME or a config option would let IT teams place it in an approved directory. Tracking this as a feature request.