Global steering files in ~/.kiro/steering/ not loaded by kiro-cli chat. I have steering files in ~/.kiro/steering/ with inclusion: always frontmatter. When I run kiro-cli chat from a project directory that has its own .kiro/steering/ folder, only the proje

[JimAva]

Checks

• I have searched github.com/aws/amazon-q-developer-cli/issues and there are no duplicates of my issue
• I have run q doctor in the affected terminal session
• I have run q restart and replicated the issue again

Operating system

macOS 26.3.1 (25D2128)

Expected behaviour

load the Global steering file at kiro-cli start up.

I have steering files in ~/.kiro/steering/ with inclusion: always frontmatter. When I run kiro-cli chat from a project directory that has its own .kiro/steering/ folder, only the project-level steering
files are injected into the session context — the global ones are ignored.

Expected behavior: Files in ~/.kiro/steering/ with inclusion: always should be loaded in every session regardless of which project directory I'm in, similar to how ~/.gitconfig applies globally.

Current workaround: Symlinking global steering files into each project's .kiro/steering/ directory.

Questions:

1. Is ~/.kiro/steering/ intended to work as a global steering directory?
2. If so, is there a config flag to enable it?
3. If not, is there a planned mechanism for user-level steering files that apply across all projects?

Environment:

• kiro-cli version: (run kiro-cli --version)
• macOS

Actual behaviour

does not load the global steering files. It load only the workspace level steering files

Steps to reproduce

kiro-cli

Environment

<This will be visible to anyone. Do not include personal or sensitive information>

[q-details]
version = "1.29.2"
hash = "874d4cb11bf441cda6122c6c8569b2322b7845b0"
date = "2026-04-03T22:01:10.564766Z (17h ago)"
variant = "full"

[system-info]
os = "macOS 26.3.1 (25D2128)"
chip = "Apple M4"
total-cores = 10
memory = "24.00 GB"

[environment]
cwd = "/Users/USER/aws-idr-alarms"
cli-path = "/Users/USER/aws-idr-alarms"
os = "Mac"
shell-path = "/bin/bash"
shell-version = "3.2.57"
terminal = "macOS"
install-method = "unknown"

[env-vars]
PATH = "/Users/USER/.aim/mcp-servers:/Users/USER/.toolbox/bin:/opt/homebrew/opt/python@3.14/libexec/bin:/opt/homebrew/bin:/Users/USER/.local/bin:/Users/USER/.local/bin/kiro-cli:/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/pmk/env/global/bin:/opt/homebrew/bin"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.apple.Terminal"

[sandikodev]

Looked into this — the steering file loading logic isn't present in the public aws/amazon-q-developer-cli repo, so this is likely handled in the Kiro-specific codebase that hasn't been upstreamed yet.

The expected behaviour makes sense though. The lookup should work like ~/.gitconfig — global files in ~/.kiro/steering/ with inclusion: always should always be loaded, with project-level files in .kiro/steering/ layered on top. Right now only the project-level ones are picked up, which means users have to symlink global steering files into every project — not great.

Flagging for the Kiro team to address in the internal codebase.