I Installed KiroCrew on Windows and Hit the 8009001d Error: Here's Every Bug, Fix, and Filed Issue
Five real demos on AWS's brand-new always-on agent: cron, memory verified on disk, subagents, and Slack, with the exact fixes for two install bugs and a GitHub issue filed live against a third.
TL;DR Installed KiroCrew natively on Windows 11 (no WSL) following the official docs* Hit two real bugs: a8009001dPowerShell error on the built-in Kiro CLI installer, and a PATH-inheritance gotcha that makes the gateway saykiro-cli not foundeven after a successful install, both have working fixes below
- Built a one-word
kclauncher that handles both gotchas automatically- Ran 5 real demos: cron scheduling, persistent memory (verified on disk, not just trusted), subagent spawning, the dashboard overview, and Slack, Slack turned up a third bug, which I filed as issue #1770
- Verdict: worth installing today if you like living on the edge of a 2-day-old repo; not yet something I'd point a Slack-dependent workflow at
Why this post exists
By the time I sat down with KiroCrew, there was already good coverage out there, the official launch post , a few trade-press pieces, and a nice first-impressions walkthrough here on Builder Center from Tinh Truong. What none of it covered: Windows, and what actually breaks when you try things for real instead of just clicking through a happy-path demo.
So that's this post. Real terminal output. Real errors. A real GitHub issue filed against a real bug. If you're on Windows and about to try KiroCrew, this should save you the hour I spent debugging.
What KiroCrew actually is (the 60-second version)
KiroCrew started as an internal Amazon tool called "MeshClaw," used by 39,000+ builders inside Amazon before AWS open-sourced it on August 4. It's a persistent, self-hosted layer on top of Kiro CLI, the pitch is "an agent that's always on," not just a chat window you open when you need it:
- Starts work unprompted: cron jobs, webhooks, and messages trigger it without you at a terminal
- One gateway, many front doors: dashboard, desktop app, CLI, and bots for Slack/Discord/Telegram/Teams, all sharing the same memory
- Actually remembers: corrections become durable "lessons," not chat history that evaporates
- Guardrails by default: sandboxing, 137 built-in denied-command patterns, approval flow, audit log
The growth numbers are wild for a 2-day-old repo: 500 contributors and 995 merged PRs in the first 2.5 weeks , per AWS Distinguished Engineer Clare Liguori and that was before public launch, counting only internal Amazon usage. As of the morning I'm writing this (Aug 6, 2026), the public repo already shows 1,276 stars, 101 forks, 49 contributors, 194 open issues, and 93 open PRs and a
v0.1.3 release shipped just yesterday. Check the repo for current numbers before you read this, they'll be stale by the time you do.Installing it: the real terminal output
I'm on Windows 11, following
docs/guides/windows-install.md . Prerequisites first: Git, Python 3.10-3.13 (I used 3.12, the tested version), Node.js optional:1
2
3
4
5
6
7
8
9
10
git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
cd website && npm install && npm run build && cd ..
Copy-Item -Recurse website\dist src\kiro_crew\static\dist
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
pip install -e ".[voice]"That part worked cleanly. Then:
1
2
kirocrew setup
kirocrew gatewayThe gateway opened the dashboard, and the first-launch flow showed exactly what the docs describe: a "Set up Kiro" screen with Install Kiro CLI (required) and Sign in to Kiro steps.
Gotcha #1: the built-in "Install Kiro CLI" button can fail with a cryptic PowerShell error
Short answer: if you see
Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d, skip the dashboard's install button and run kiro-cli login directly in a normal PowerShell window instead.Clicking Install Kiro CLI kicked off a download-and-run flow and failed:
1
2
3
⚠ Kiro CLI installation did not complete.
Internal Windows PowerShell error.
Loading managed Windows PowerShell failed with error 8009001d.That error code (
0x8009001D, NTE_FAIL) is a Windows CryptoAPI failure, not a KiroCrew bug specifically, but the restricted subprocess environment KiroCrew spawns the installer in in this flow can trip it. The fix: run the official installer directly yourself, outside that restricted subprocess:1
kiro-cli loginIf
kiro-cli isn't on PATH yet, grab it via the official install script referenced in kiro_prerequisite.py (https://cli.kiro.dev/install.ps1) and run it in a normal PowerShell window, not through the dashboard button. It completes cleanly that way.Gotcha #2: kiro-cli installs fine, but the gateway won't see it until you restart with a refreshed PATH
Short answer: Windows doesn't propagate PATH updates to already-running processes, stop the gateway, refresh
$env:Path from the registry in the same shell, then restart it.Even after
kiro-cli was installed and I confirmed it with kiro-cli whoami, the gateway kept saying kiro-cli not found in PATH. This is a classic Windows environment-inheritance issue: the gateway process was started before the installer updated the user PATH, and Windows doesn't propagate PATH changes to already-running processes.The fix: refresh PATH from the registry in the same shell session before restarting the gateway:
1
2
3
kirocrew stop
$env:Path = [Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [Environment]::GetEnvironmentVariable("Path","User")
kirocrew gatewayThe giveaway: a one-word launcher that handles both gotchas for you
I got tired of retyping that, so I built
kc : a .cmd shim that stops any stale gateway, refreshes PATH, starts the gateway, waits until it's actually serving (not just "process started"), grabs a fresh auth token, and opens the dashboard in Chrome specifically:1
2
@echo off
powershell -NoProfile -ExecutionPolicy Bypass -File "%~dp0start-kirocrew.ps1"Drop
start-kirocrew.ps1 (the readiness-polling script) and kc.cmd in a folder already on your PATH, I used %USERPROFILE%\.local\bin and from then on, any terminal, any time: just type kc.[If you want the full script, I'm happy to share it as a Gist, say so in the comments.]
Putting it to work: five real demos
Once it was running, I didn't just poke at the UI, I actually used it. Here's what happened, unedited.
1. Cron jobs: a live GitHub tracker, not just a toy demo
My first attempt at a cron job (a daily "greet me with a motivational quote" job) actually got stuck showing "Running" indefinitely with no output, a real rough edge on Windows. Rather than just report that and move on, I gave it a harder, more useful job: watch this very repo in real time.
"Every hour, check the kirodotdev/KiroCrew GitHub repo's star count, fork count, and open issue count, and log how they've changed since the last check."
KiroCrew reasoned about the request out loud before touching anything: "This is a deterministic polling task with no reasoning needed each cycle, a script cron is the right fit (zero tokens per run). I'll write a script that fetches repo stats via GitHub's public API, diffs against the last saved snapshot, and reports changes." Same smart default as before, no LLM call spent on something a script can do, just applied to something genuinely useful instead of a novelty.
The approval gate for `github_repo_watch.py`, a ~90-line script it wrote and asked permission to create before running anything.
Scheduled. Job `9a8be091` runs `github_repo_watch.py:check` every hour against `kirodotdev/KiroCrew` via GitHub's public API, zero LLM tokens per run since it's a pure script cron.
KiroCrew Schedule page showing the GitHub repo watch cron job with OK status and a next run in 59 minutes.
I triggered it manually to see the baseline it captured:
KiroCrew chat reporting a live baseline of GitHub stars, forks, and open issues for the KiroCrew repo.
This is the version of "agent scheduling" that actually sells the pitch: not a canned quote-of-the-day, but an agent that wrote its own monitoring script, reasoned about cost (script vs. LLM call), designed its own noise-suppression logic (diff-and-notify instead of spamming every hour), and handled a real-world failure mode (API rate limits) without being told to. If you want to see the same thing for your own repo, the prompt above is copy-paste-ready, just swap the repo name.
2. Persistent memory: a lesson that rewrote live code, then explained itself
Every existing review praises this feature, so I wanted a test with a real bar to clear: does a lesson taught once actually change what gets built later, in a session that's never seen it, and can the agent correctly explain why it did something differently, rather than just recalling a fact?
Still in the same session as the GitHub-tracker cron job above, I taught it a real engineering judgment call:
"Remember this for all future sessions: whenever you write a script that reports GitHub repo growth (stars, forks, issues), always compute and include the percentage change since the last baseline, not just the raw delta, raw numbers alone are meaningless without knowing the growth rate, especially for a repo moving this fast."
KiroCrew chat where a persistent lesson about including percentage growth in repo-tracking scripts is taught.
KiroCrew diff showing the live cron script retroactively updated to include percentage-growth calculations.
Then I opened a completely new session, different chat, no shared context and gave it a generic prompt with zero mention of percentages:
"Write me a script that checks how a GitHub repo's stats have changed since a previous snapshot."
A brand-new KiroCrew session building a standalone GitHub stats-diff script from a generic request.
I asked, "Is there percentage growth?", confirming it had applied the rule without being told again, with real numbers from a live test run:
KiroCrew confirming percentage-growth calculations were included automatically in a new script, with real GitHub numbers.
Then the actual proof, I asked it directly why it did that without being told:
"Why did you include percentage growth just now, I didn't ask for that."
KiroCrew explaining that a design decision came from a specific persistent lesson, quoting the saved lesson text back exactly.
That's a meaningfully higher bar than "it remembered my formatting preference": it retroactively patched code that was already live and scheduled, applied the same standard unprompted to an unrelated task in a different session, and when challenged, correctly cited its own stored reasoning instead of confabulating an explanation. That third part is the one that matters: a lot of "memory" demos show recall, not many show an agent that can accurately explain why it just did something.
3. Subagents: three agents doing real triage on this repo's actual open bugs
I didn't want a novelty demo here either, so I pointed three parallel subagents at real, currently-open GitHub issues, including two (#1572 , #1589 ) already referenced earlier in this post:
"Spawn 3 parallel subagents to investigate GitHub issues #1572, #1673, and #1589 on kirodotdev/KiroCrew. For each one, have the subagent read the issue and its comments via the gh CLI, then report back: the likely root cause, a severity rating (blocker / annoyance / cosmetic), and whether it looks like it's already been fixed by a newer commit or PR since it was filed. Then synthesize all three into one triage summary, and flag if any of them look like they share the same underlying root cause."
KiroCrew spawning three parallel subagents, each with its own approval gate, to investigate real GitHub issues.
Watching one subagent's live tool panel mid-run showed genuinely deep investigation, not a surface-level summary, reading crash dumps, checking an open PR's actual diff scope, and proactively pulling extra data to cross-reference against the other two subagents' findings:
KiroCrew subagent's live tool panel showing detailed GitHub issue investigation with cross-referencing.
All three finished, and it didn't just concatenate their reports, it actually cross-referenced them and found a real, non-obvious connection:
KiroCrew triage summary for two GitHub issues with root cause, severity, and fix status for each.
KiroCrew explaining that two of three investigated issues share a real underlying root cause, on Windows process management.
KiroCrew synthesis showing severity ranking and fix status verified against actual open pull requests.
I pushed it further with a follow-up:
"Which of these should I fix first, and why?"
KiroCrew giving a reasoned bug-fix prioritization order with tradeoffs explained, not just a severity list.
This is the subagents feature actually doing something an AWS engineer would recognize as useful work: three agents independently investigating live, real bugs, then synthesizing findings the way a human triage session would, spotting a shared root cause, catching that "has an open PR" doesn't mean "is fixed," and producing a prioritization call with real tradeoffs instead of just sorting by severity label.
4. The dashboard's system overview and one small honest caveat about it
I checked this panel right after the cron, memory, and subagent demos above, expecting it to double as a running tally proving it had all happened. It doesn't, quite:
KiroCrew Settings Overview panel showing system uptime, session/cron/subagent/lesson counts, and today's usage stats.
Small but useful thing to know if you're ever sanity-checking your own activity here: this panel is a live pulse, not a lifetime odometer, for anything that needs to survive a restart, check the Schedule page (as shown above, cron jobs persist there) or the memory tool's own listing, not this counter.
5. Slack integration: connected, but here's an honest gap
Setup itself was smooth: Settings → Channels → Slack → Create Slack app opens a pre-filled manifest (Socket Mode + permissions already configured), you install it, paste the bot and app tokens, and set an Owner Slack member ID, the "only I can trigger it" field that got real love in the Builder Center comments.
KiroCrew Slack integration settings panel with bot token, app token, and Owner Slack member ID fields.
After saving and restarting the gateway, the dashboard showed Slack: Connected, and the bot's Slack App Home correctly rendered live status (gateway uptime, active cron jobs, sessions), genuinely nice touch.
But when I actually DMed the bot: "Hey! Are you working? Just say hi back", nothing happened. No reply, no reaction emoji, for 40+ seconds. And the gateway's own logs showed zero activity for the message at all.
Digging into the crash logs, I found the same error recurring across every gateway restart that evening:
1
2
ASYNCIO UNHANDLED: Exception in callback _ProactorBasePipeTransport._call_connection_lost(None)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote hostThis is a known category of Windows
asyncio bug, ProactorEventLoop has documented issues with how WebSocket libraries tear down connections, and KiroCrew's own AGENTS.md already documents one unrelated Windows/ProactorEventLoop fix in this exact file. My working theory: the Socket Mode connection resets on Windows and doesn't fully recover event delivery, while the dashboard's "Connected" badge only reflects the initial handshake, not live event flow.I filed it: github.com/kirodotdev/KiroCrew/issues/1770 , with the full sanitized crash log, the suspected file/line (
slack/gateway.py), and a concrete theory for maintainers to check. If you hit the same thing, +1 the issue or comment with your repro, that's how this gets fixed faster than any one person debugging alone.What's honestly still rough on Windows
Per KiroCrew's own docs, several features are explicitly not-yet on Windows: Piper voice TTS (no Windows binary upstream), the SSH tunnel for remote dashboard access, and PR-source-drawer provider fetching (needs a POSIX sandbox). Add to that what I found tonight: the two install gotchas above, a cron job that can get silently stuck in "Running," and the Slack message-delivery gap in #1770 .
I'm not the only one hitting Windows-specific friction, the tracker already has a cluster of open Windows issues beyond mine: #1572 (gateway watchdog trips), #1673 and #1648 (flaky/failing Windows test shards), #1589 (native force-stop), and #1708 (frame redelivery on Windows). None of that is a knock on the project, it's two days old, already on
v0.1.3, and moving at 995-merged-PRs-in-2.5-weeks pace. It's exactly what you'd expect from a brand-new native Windows port, and it's the kind of thing that gets fixed fast in a project this active.My honest verdict: would I run this in production on Windows today? Not for anything Slack-dependent, not until #1770 lands a fix. Would I keep using it for cron + memory + subagents on my own machine? Yes, without hesitation, those three worked exactly as advertised once I got past the install gotchas, and the persistent-memory feature alone is worth the friction.
Try it yourself
1
git clone https://github.com/kirodotdev/KiroCrew.gitFull install steps:
docs/guides/windows-install.md . If you hit the PowerShell 8009001d error or the PATH gotcha, you now know exactly what's happening and how to fix it. If you're chasing the Slack issue, #1770 has everything I found.One thing I couldn't confirm: whether the PATH gotcha (Gotcha #2) also happens on a non-admin Windows account, or only shows up on setups like mine. If you've hit it, either way, tell me your account type and Windows build in the comments; it'll help narrow down whether this needs its own issue filed. And if you're on Slack and get a DM through successfully where I couldn't, I'd genuinely like to know what's different about your setup, that's the fastest way #1770 gets fixed.
I'll follow up once the Slack issue gets a maintainer response, and once I've had a few real days living with the memory/lessons feature instead of just testing it in one sitting.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article