Debugging Kiro's zsh CLI Session Issues: Missing Command Return Values

Published:
  Lastmod: 2025-09-26
Problem Solving
by Ernest Chiang

Kiro and zsh Interaction Issues

Problem Description

Recently, while playing with Kiro (Agentic IDE) and experimenting with multiple-role agents and hooks, I encountered a quite frustrating problem: within the same CLI session, Kiro couldn't retrieve the return values from the second command.

The problem scenario was as follows:

  • When I asked Kiro to execute the first command, everything worked perfectly - the command executed successfully and could retrieve the output correctly.
  • However, when executing the second command within the same shell session, Kiro would be unable to get the return value from that command.
  • So Kiro would just hang there waiting for the response, unable to get the vibe going.

This problem significantly impacted my workflow:

  • Frequent session restarts:
    • After executing the first command, I had to manually close the CLI session each time. If I need to intervene this frequently as a human, that’s not the AI agent I want.
  • Manual output copying:
    • Or I needed to manually copy the return values from the second command to Kiro Chat.
  • Reduced work efficiency:
    • The originally smooth agentic coding workflow became fragmented. While I can relax when it’s time to relax, for work tasks, I want to improve efficiency.

Problem scenario video record (some key information in the video has been regenerated, please don’t panic):

Initial Investigation Directions

  • Facing this problem, I started making educated guesses based on past experiences.
  • The first suspect I thought of was Amazon Q CLI as one of the potential culprits.
  • Additionally, my environment might be relatively complex. You can refer to my dotfiles git repo to study it slowly. If anyone can help me redesign how to simplify it, I would be very grateful.

Concerns About Amazon Q CLI

I had encountered similar issues when using Cursor previously. According to my understanding, Amazon acquired a company called fig and integrated it into Q CLI.

This integration might have caused the following issues:

  • Multi-layer shell invocation:
    • When Cursor or Kiro launches a CLI session (shell)
  • Automatic takeover mechanism:
    • Q CLI might automatically start and take over this session
  • Output transmission problems:
    • Too many hands in the chain preventing std output (stdout) from reaching back to the original Cursor/Kiro

This multi-layered architecture can easily cause output to fail to return properly to the original Agentic Coding Chat environment, especially when executing multiple commands consecutively (usually the second command would get stuck).

At that time, I changed Cursor IDE to use my local bash shell (relatively clean), but the downside was that Cursor couldn’t access all the environment variables and tools I had configured in zsh, which for me meant reduced efficiency and duplication of work. I didn’t really want this kind of solution.

# Amazon Q post block. Keep at the bottom of this file.
# Only load Amazon Q in non-Cursor and non-Kiro environments to avoid conflicts
if [[ "$TERM_PROGRAM" != "cursor" ]] && [[ -z "$CURSOR_SESSION" ]] && [[ "$TERM_PROGRAM" != "kiro" ]]; then
    [[ -f "${HOME}/Library/Application Support/amazon-q/shell/zshrc.post.zsh" ]] && builtin source "${HOME}/Library/Application Support/amazon-q/shell/zshrc.post.zsh"
fi

.zshrc Configuration Considerations

Additionally, I noticed that my .zshrc already had the Manual Shell Integration Installation settings according to Kiro documentation recommendations. This made me start suspecting whether certain shell configurations were creating conflicts with Kiro’s interaction mechanisms.

# Kiro shell integration - Load first to ensure proper session handling
[[ "$TERM_PROGRAM" == "kiro" ]] && . "$(kiro --locate-shell-integration-path zsh)"

Solution

After the brute-force debugging method described below, I finally discovered that the root of the problem was not in Amazon Q CLI, but in my ZSH_THEME configuration.

But first, let me explain to everyone that my colleague also made the same ZSH_THEME configuration adjustment as I did, but he still experienced the problem. So going back to the source, everyone’s computer environment at any given time is definitely different. We can only use the line-by-line elimination method introduced below (quite brute-force, right?) to find where the breaking point is after the layering of each computer’s environment. So strictly speaking, it’s not really finding the root cause, but rather the final pressure release point for that particular computer’s environment.

Line-by-Line Elimination Debugging

I decided to use the most direct approach: commenting out the settings in `.zshrc` line by line to see which line was causing trouble.

After commenting out a certain line, go back to Kiro (or the Agentic Coding IDE you’re having problems with) and ask it to test three consecutive commands in the same CLI session. (You can refer to the second video below for the test prompt.)

This process was somewhat tedious, but very effective. By using a binary search approach to gradually narrow down the scope, I finally found where the problem was.

The Root Cause: powerlevel10k (in my case)

It turned out that the culprit was this line in my .zshrc:

ZSH_THEME="powerlevel10k/powerlevel10k"

Conditional Shell Theme Switching

After confirming the problematic line, the next step was to think about how to maintain the visual experience of using powerlevel10k normally while ensuring Kiro works properly. I asked Kiro (or was it Claude Code?! I forgot, but I’ve been mostly using Claude Sonnet 4 for models lately) to implement a conditional judgment solution:

if [[ "$TERM_PROGRAM" != "kiro" ]]; then
    ZSH_THEME="powerlevel10k/powerlevel10k"
else
    # Use simple theme in Kiro to avoid CLI session conflicts
    ZSH_THEME="robbyrussell"
fi

The logic of this solution is simple:

  • Under normal circumstances: Use the powerlevel10k theme to maintain a beautiful terminal experience
  • In the Kiro environment: Automatically switch to the simple robbyrussell theme to avoid interaction conflicts

By checking the $TERM_PROGRAM environment variable, we can accurately identify whether we’re currently executing in Kiro’s CLI session.

Moreover, the entire .zshrc is shared across various scenarios, so all my previous environment variables and tools can be reused without exception handling or workarounds.

Verification

After implementing the above solution, the problem was resolved and has disappeared.

Right after the fix, Kiro immediately helped me create a PR to the aws-cdk project.

The effects after the fix were very satisfactory:

  • Consecutive command execution works normally: (This was the main issue) In the same CLI session, Kiro can now properly retrieve return values from all subsequent commands.
  • Smooth workflow: (The value brought by solving the problem) No longer need to frequently restart sessions or manually copy output content.
  • Best of both worlds: (Maintaining the consistency I pursue in every project) Keep my familiar powerlevel10k appearance normally, while automatically switching to a compatible theme in Kiro.

Fixed working video (no comedy version):

Bottomline

The more brute-force the solution, the more I like it - it usually applies to more diverse scenarios. (Getting beaten up XDD

Buy Me a Coffee If this sharing helps you, feel free to buy me a coffee ☕ :)

References

Additionally, I occasionally have AI workflow integration side projects and experience sharing sessions coming up. Welcome friends interested in exploring AI-assisted development workflows to message me at LinkedIn @dwchiang.