AWS Builder Center

Builder Center

How I Recovered a Lost Kiro AI Brainstorming Session — And What I Learned About Where Kiro Actually Stores Your Work

A technical deep-dive for builders who've lost a session and don't know where to look.

The Setup

I was in the middle of a deep brainstorming session with Kiro — designing an app for the AWS weekend Challenge. We'd gone back and forth for a while, iterating on the architecture, trimming unnecessary AWS services, deciding how to use Bedrock Nova Lite, confirming CORS gotchas and verifying free tier costs and these are the kind of work and research you don't want to miss or repeat.
Then the session disappeared. YESSSS, it disappeared!!!
I tried everything the documentation suggested. I ran kiro-cli chat --resume. Nothing relevant came up. I tried kiro-cli chat --resume-picker. Still nothing.
I almost gave up and planning to restart my entire work again, but my frustration got the better of me and i started digging into my finder, going through various .kiro folders, hidden files and then i found my way through Shift+Command+G , where I search through /Users/Username/Library/Application Support/Kiro/User/globalStorage/Kiro.Kiroagent path and found something incredible!!
As a student, i found it fascinating when i found the history of most of my chat session piled up in different file names with random numbers and this excitement got the best of me and finally after few minutes of searching i found the file !!
A file named — 32a97b830f8e715781137f5e56444d64 And I gave it to Kiro-Cli and asked it to find the session. The response was:
"There's no session with ID 32a97b830f8e715781137f5e56444d64."
Kiro was right. And also completely wrong.
Here's what was actually happening — and how I found the session myself.

Why Kiro Said "No Session Found" (And Was Correct)

Kiro CLI auto-saves sessions to:
1
~/.kiro/sessions/cli/
Every session gets a UUID filename like:
1
2
3
4
f9290f4a-aee0-4390-9212-159c52eaf591.json
f9290f4a-aee0-4390-9212-159c52eaf591.jsonl
f9290f4a-aee0-4390-9212-159c52eaf591.history
f9290f4a-aee0-4390-9212-159c52eaf591.lock
The string I had — 32a97b830f8e715781137f5e56444d64 — doesn't match that UUID format at all. It's a 32-character hex string with no dashes. Kiro's session system uses UUID v4 (32 hex chars with dashes: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). So when Kiro searched ~/.kiro/sessions/cli/ for that filename, it correctly found nothing.
But that was the wrong place to look.

Where the File Actually Was

The session I was looking for wasn't a Kiro CLI session file. It was a Kiro IDE agent execution log — a completely different storage system.
I ran:
1
find ~ -name "32a97b830f8e715781137f5e56444d64*" 2>/dev/null
And found it at:
1
~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/default/414d1636299d2b9e4ce7e17fb11f63e9/32a97b830f8e715781137f5e56444d64
Let's break down what each part of that path means:
Path SegmentWhat It Is
~/Library/Application Support/Kiro/Kiro IDE's VS Code-style user data directory (macOS)
User/globalStorage/VS Code extension global storage — persists across workspaces
kiro.kiroagent/The Kiro agent extension's storage namespace
default/Default workspace context
414d1636299d2b9e4ce7e17fb11f63e9/A hash of the workspace/directory context
32a97b830f8e715781137f5e56444d64The agent execution file itself
This file is not a Kiro CLI session. It's a Kiro IDE agent execution record — stored by the VS Code extension, not the CLI. That's why kiro-cli chat --resume and --resume-picker couldn't see it. They look in an entirely different location.

The Two Storage Systems: CLI vs IDE

This is the core thing to understand. Kiro has two separate agents with two completely separate storage systems:

Kiro CLI Sessions

  • Location: ~/.kiro/sessions/cli/
  • Triggered by: kiro-cli chat
  • Format: UUID filenames (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
  • Files per session: .json (metadata), .jsonl (conversation log), .history, .lock
  • Scope: Per-directory (scoped to the folder you were in)
  • Resume commands: --resume, --resume-picker, --resume-id

Kiro IDE Agent Executions

  • Location: ~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/ (macOS)
  • Triggered by: Chatting with Kiro inside the IDE
  • Format: 32-char hex filenames (MD5-style hashes)
  • Content: Full execution logs including intent classification, tool calls, web searches, model responses, and the complete conversation
  • Scope: Not directory-scoped in the same way
  • Not accessible via CLI resume commands
When I ran kiro-cli chat --resume-picker, it was looking in the CLI session store. My brainstorming session had happened inside the Kiro IDE, not the terminal. Different tool, different storage, different recovery path.

What the Execution File Actually Contains

Once I opened the file, I found it was a rich JSON record of the entire agent execution. It has:
1
2
3
4
5
6
7
8
9
{
"executionId": "534ebd14-f977-459d-9f54-b2f6244d1aa1",
"workflowType": "chat-agent",
"status": "succeed",
"startTime": 1785521113715,
"input": { ... }, // Full conversation history
"actions": [ ... ], // Every tool call, web search, model response
"context": { ... } // Session metadata
}
The actions array is particularly detailed — it logs every web search query and result, every MCP tool call, every model response, every file the agent read. This is not just the chat transcript. It's a complete audit trail of everything the agent did.
This meant I could reconstruct the entire brainstorming session, including the research the agent had done on AWS Lambda Function URLs, Bedrock Nova Lite pricing, CORS configuration, file upload limits — all of it.

How to Find a Lost IDE Session

If you were chatting with Kiro inside the IDE (not the terminal), here's how to recover it:
Step 1: Run a filesystem search
On macOS:
1
find ~/Library/Application\ Support/Kiro -name "*" -newer ~/.kiro/sessions/cli/ 2>/dev/null
Or if you have part of the filename:
1
find ~ -name "32a97b830f8e715781137f5e56444d64*" 2>/dev/null
On Linux:
1
find ~/.config/Kiro -type f 2>/dev/null | head -20
Step 2: Look in the right directory
1
ls -lt ~/Library/Application\ Support/Kiro/User/globalStorage/kiro.kiroagent/default/
Each subdirectory under default/ is a hash of your workspace context. The files inside are execution records. Sort by modification time to find recent ones.
Step 3: Read the file
The file is plain JSON. Open it in any editor or use:
1
cat /path/to/execution-file | python3 -m json.tool | less
Look for messagesFromExecutionId inside input.data — that's your conversation history. The actions array has all tool calls and model responses.

What the CLI --resume Commands Can and Can't Do

To save other builders from the same confusion, here's a clear breakdown:
CommandWhat It AccessesWhat It Misses
kiro-cli chat --resumeLast CLI session in current directoryIDE sessions, other directories
kiro-cli chat --resume-pickerAll CLI sessions in current directoryIDE sessions
kiro-cli chat --resume-id <id>Specific CLI session by UUIDIDE sessions
kiro-cli chat --list-sessionsCLI sessions in current directoryIDE sessions
/chat load <path>Any exported .json or .zip fileSessions never exported
None of these commands touch the IDE's globalStorage. They are strictly for the CLI session store at ~/.kiro/sessions/cli/.

Preventing This in the Future

A few habits that will save you:
1. Export important sessions immediately after a brainstorming session in the CLI:
1
/chat save ~/brainstorming/project-name-2026-08-01.json
2. Use the CLI for important sessions, not just the IDE. CLI sessions are easier to manage, list, and resume.
3. Keep note of the session ID. When you start a session in the IDE, the agent execution ID is visible in the logs. Note it down somewhere.
4. The find command is your friend. If anything goes missing, find ~ -name "filename" 2>/dev/null will locate it anywhere on your filesystem regardless of which tool created it.

The Bigger Lesson

The root confusion here was assuming one tool's session management applied to both tools. Kiro CLI and Kiro IDE are two separate surfaces. They share the same AI agent but store their state independently. The CLI is the terminal interface; the IDE is the VS Code extension. When you chat in the IDE, the execution record goes to the VS Code extension's globalStorage — not the CLI's session directory.
This isn't a bug. It's a natural consequence of two different tools being built on different foundations. The CLI uses its own lightweight session file format. The IDE uses VS Code's extension storage API. They don't share a session store.
Once I understood that distinction, finding the file was trivial. A single find command from the home directory was all it took.
The brainstorming session was intact. Every web search result, every architectural decision, every verified cost estimate — all recoverable. I picked up exactly where I left off.
  • Kiro CLI sessions → ~/.kiro/sessions/cli/ (UUID filenames)
  • Kiro IDE agent executions → ~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/ (hex filenames)
  • --resume and --resume-picker only work for CLI sessions
  • To find a lost IDE session: find ~ -name "<filename>" 2>/dev/null
  • Export important sessions with /chat save <path> after every significant conversation
If you've hit a similar problem with a lost session, the find command is the first thing to reach for — before assuming the session is gone. Happy learning and building everyone !!!
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