Global steering files with "inclusion: fileMatch" are not injected into agent context

[msayed-treezor]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

macOS 26.3

Kiro Version

0.8.140

Bug Description

Global steering files placed in ~/.kiro/steering/ are not loaded into the agent context, regardless of the inclusion mode (always, fileMatch, or manual).

I have 24 .md files in ~/.kiro/steering/ with various inclusion modes. When I work on a PHP project and open or edit .php files, files configured with inclusion: fileMatch and fileMatchPattern: '**/*.php' are never injected into the agent context.

The agent has no knowledge of my quality gates (PHPUnit, PHPStan, Pint), my PHP/Laravel conventions, or my test commands. When I ask "what are your steering rules?", it only mentions workspace-level .kiro/steering/ files, never the ones from ~/.kiro/steering/.

Example file that doesn't load — ~/.kiro/steering/40-quality-standards.md:

inclusion: fileMatch
fileMatchPattern: '**/*.php'

Quality Standards

(contains quality gates for PHPUnit, PHPStan, Pint)

Same issue with:

• 06-php-laravel.md (fileMatch **/*.php)
• 21-phpunit-tests.md (fileMatch /tests//*.php)
• 07-terraform.md (fileMatch **/*.tf)

The current workspace does NOT have a .kiro/steering/ directory, so there is no priority conflict.

I manage 25 PHP projects with the same stack. Global steering is the reason I centralized my rules in ~/.kiro/steering/ instead of duplicating them in every workspace. Without this feature working, the global steering introduced in v0.5 is unusable for my use case.

Refs:

• Blog: https://kiro.dev/blog/stop-repeating-yourself/
• Changelog v0.5: https://kiro.dev/changelog/ide/0-5/
• Docs: https://kiro.dev/docs/steering/

Steps to Reproduce

1. Place .md files in ~/.kiro/steering/ with front-matter inclusion: fileMatch and a pattern like **/*.php
2. Open a project that contains .php files but does NOT have a .kiro/steering/ directory (no conflict)
3. Open or edit a .php file in the project
4. Ask the agent to perform a task on that file (e.g. "add an endpoint and run the tests")
5. Observe that the agent has no knowledge of the rules defined in the global steering files
6. Ask the agent "what are your steering rules?" — it does not mention any file from ~/.kiro/steering/

Also tested with inclusion: always on global files, same result.

Expected Behavior

When working on a .php file, global files in ~/.kiro/steering/ with fileMatchPattern: '**/*.php' should be automatically injected into the agent context, as described in the official docs and blog. Files with inclusion: always should be loaded in every conversation without exception.

Conversation ID

N/A

Additional Context

• Kiro 0.8.140, macOS 26.3 (25D125), MacBook Air M1 2020, 16GB RAM
• 24 files in ~/.kiro/steering/, mix of always/fileMatch/manual
• Workspace has no .kiro/steering/ directory (zero possible conflict)
• Tested on multiple different PHP projects, same result
• Tested with both inclusion: always and inclusion: fileMatch, neither works at the global level
• Reproducible on every new conversation

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #5027: Conditional inclusion in global steering doesn't work (95% similar)
• #4968: Steering: Manual inclusion works differently in global and local steering for typed-in hashtags. (85% similar)
• #4156: Steering File Resolution Error : Cannot read properties of undefined (reading 'startsWith') (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both report that global steering files with conditional inclusion (fileMatch patterns) are not working - same core functionality failure with nearly identical symptoms

[github-actions]

This issue has been automatically closed as it appears to be a duplicate of #5027.

If you believe this is incorrect, please comment on this issue and a maintainer will review it.