Checks
Operating system
macOS 26.4.0 (25E246)
Expected behaviour
Kiro-CLI runs on the local Mac, executes tasks, and writes output files directly to specified local folders (e.g., ~/, ~/projects/) as it had been
doing for the past week without issue.
Actual behaviour
After the kiro-CLI auto-update on April 13–14, 2026, the tool runs and processes tasks normally but silently fails to write output files to local Mac
folders. File writes are blocked by the Ava Reveal DLP (Data Loss Prevention) agent, which re-evaluated kiro-CLI as a newly seen binary after the
update and applied a restrictive write policy.
Impact
All tool output is lost — work completes inside kiro-CLI but no files are saved to disk.
The investigation already found strong evidence pointing to your corporate security solution. Here's a clear breakdown:
Root Cause: Ava Reveal DLP Agent (Data Loss Prevention)
What Was Found
- Kiro-CLI was updated April 13-14, 2026 — right before the problem started:
- /Applications/Kiro CLI.app/Contents/MacOS/kiro-cli — updated Apr 13, 17:00
- ~/Library/Application Support/kiro-cli/bun — updated Apr 14, 20:43
- Symlink ~/.local/bin/kiro-cli — recreated Apr 14, 20:37
- Ava Reveal DLP Agent is actively running on your Mac:
- Installed at /Library/SystemExtensions/
- The kiro-cli binary itself has DLP tracking metadata attributes:
- com.nextdlp.reveal.agent.file-id.0
- com.nextdlp.reveal.agent.file-source-path.0
- Active helper: ~/Library/Preferences/uk.ava.reveal.Reveal-Agent-Helper.plist
- Docker is NOT the cause — Docker Desktop is installed but the daemon is not running. This is not a container isolation issue.
Why It Broke After the Update
The kiro-cli update likely triggered a DLP policy re-evaluation. When the binary hash/signature changed, the Ava agent treated it as a newly seen
application and applied a restrictive default policy — blocking file writes to arbitrary local paths to prevent data exfiltration.
How to Fix It
Option 1 — Ask your IT/Security team (recommended):
- Ask them to whitelist kiro-cli in the Ava Reveal DLP policy
- Specifically: allow file writes to your working directories (e.g., ~/, ~/projects/)
- Reference the binary: /Applications/Kiro CLI.app/ signed by Amazon (Team ID: 94KV3E626L)
Option 2 — Test a workaround yourself:
Try writing to /tmp/ first to confirm DLP is the blocker:
If kiro-cli can write to /tmp but not ~/ — DLP is confirmed
kiro --output /tmp/test-output.txt
Option 3 — Check DLP logs (may need admin):
ls /Library/Application\ Support/uk.ava.reveal.agent.sysmon/
Option 4 — Check extended attributes on the binary:
xattr -l /Applications/Kiro\ CLI.app/Contents/MacOS/kiro-cli
If you see the com.nextdlp.reveal.* attributes, DLP is confirmed as tracking it.
Summary
┌───────────────┬────────────────────────────────────────────────────────┐
│ Factor │ Detail │
├───────────────┼────────────────────────────────────────────────────────┤
│ Root cause │ Ava Reveal DLP Agent blocking file writes │
├───────────────┼────────────────────────────────────────────────────────┤
│ Trigger │ Kiro-CLI v2.0.0 update (Apr 13-14) changed binary hash │
├───────────────┼────────────────────────────────────────────────────────┤
│ Not the cause │ Docker (daemon is stopped) │
├───────────────┼────────────────────────────────────────────────────────┤
│ Fix │ IT team whitelist of kiro-cli binary in DLP policy │
└───────────────┴────────────────────────────────────────────────────────┘
Steps to reproduce
none
Environment
<This will be visible to anyone. Do not include personal or sensitive information>
[q-details]
version = "2.0.0"
hash = "0026b0505ef7bc2b10780c7bdb57813e5d949747"
date = "2026-04-13T09:10:32.211225Z (2d ago)"
variant = "full"
[system-info]
os = "macOS 26.4.0 (25E246)"
chip = "Apple M3 Pro"
total-cores = 11
memory = "18.00 GB"
[environment]
cwd = "/Users/USER"
cli-path = "/Users/USER"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.9"
terminal = "macOS"
install-method = "brew"
[env-vars]
PATH = "/Users/USER/.toolbox/bin:/Users/USER/.local/bin:/Users/USER/Library/Python/3.9/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/pkg/env/active/bin:/opt/pmk/env/global/bin:/Users/USER/.local/bin"
QTERM_SESSION_ID = "3d15a54476bb450da6cbdda5a861850e"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "2.0.0"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.apple.Terminal"
Checks
q doctorin the affected terminal sessionq restartand replicated the issue againOperating system
macOS 26.4.0 (25E246)
Expected behaviour
Kiro-CLI runs on the local Mac, executes tasks, and writes output files directly to specified local folders (e.g., ~/, ~/projects/) as it had been
doing for the past week without issue.
Actual behaviour
After the kiro-CLI auto-update on April 13–14, 2026, the tool runs and processes tasks normally but silently fails to write output files to local Mac
folders. File writes are blocked by the Ava Reveal DLP (Data Loss Prevention) agent, which re-evaluated kiro-CLI as a newly seen binary after the
update and applied a restrictive write policy.
Impact
All tool output is lost — work completes inside kiro-CLI but no files are saved to disk.
The investigation already found strong evidence pointing to your corporate security solution. Here's a clear breakdown:
Root Cause: Ava Reveal DLP Agent (Data Loss Prevention)
What Was Found
Why It Broke After the Update
The kiro-cli update likely triggered a DLP policy re-evaluation. When the binary hash/signature changed, the Ava agent treated it as a newly seen
application and applied a restrictive default policy — blocking file writes to arbitrary local paths to prevent data exfiltration.
How to Fix It
Option 1 — Ask your IT/Security team (recommended):
Option 2 — Test a workaround yourself:
Try writing to /tmp/ first to confirm DLP is the blocker:
If kiro-cli can write to /tmp but not ~/ — DLP is confirmed
kiro --output /tmp/test-output.txt
Option 3 — Check DLP logs (may need admin):
ls /Library/Application\ Support/uk.ava.reveal.agent.sysmon/
Option 4 — Check extended attributes on the binary:
xattr -l /Applications/Kiro\ CLI.app/Contents/MacOS/kiro-cli
If you see the com.nextdlp.reveal.* attributes, DLP is confirmed as tracking it.
Summary
┌───────────────┬────────────────────────────────────────────────────────┐
│ Factor │ Detail │
├───────────────┼────────────────────────────────────────────────────────┤
│ Root cause │ Ava Reveal DLP Agent blocking file writes │
├───────────────┼────────────────────────────────────────────────────────┤
│ Trigger │ Kiro-CLI v2.0.0 update (Apr 13-14) changed binary hash │
├───────────────┼────────────────────────────────────────────────────────┤
│ Not the cause │ Docker (daemon is stopped) │
├───────────────┼────────────────────────────────────────────────────────┤
│ Fix │ IT team whitelist of kiro-cli binary in DLP policy │
└───────────────┴────────────────────────────────────────────────────────┘
Steps to reproduce
none
Environment