You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
kiro-cli v3: /tools lists write for an agent with "tools": ["read"], but the agent cannot use it #12113
For an agent whose tools list contains only read, /tools shows a write tag as well. The agent does not actually have it: asked to write a file, the model answers that it has no write tool and nothing is written. So /tools shows a tool set that differs from the one the agent really gets, which makes it hard to check an agent's configuration.
Steps to Reproduce
Create .kiro/agents/readonly.json:
{"name":"readonly","description":"read only","prompt":"You are terse.","tools":["read"],
"permissions":{"rules":[{"capability":"fs_read","effect":"allow"}]}}
Run kiro-cli chat --agent readonly, then /tools. Observed:
Send Use your write tool to create the file /tmp/w.txt containing the word hi. Do not use shell. Observed: I don't have a write/file-creation tool available — only read and search tools. I can't create the file. No approval prompt; the file is not created.
Expected Behavior
/tools lists only the tools the agent can use (read here).
Conversation ID
No response
Additional Context
The same extra write tag appears with "tools": ["read", "@<mcp-server>"] (one more tag than listed).
Thanks for opening this issue and for the clear, detailed reproduction steps! 🙏 It's a great catch that /tools is displaying tools (like write) that aren't actually available to the agent, making it tricky to verify an agent's real configuration. A maintainer will take a look at this shortly — we appreciate you helping us make the CLI experience more accurate and reliable!
For an agent whose tools list contains only "read", the /tools command displays a write tag as well. The agent correctly refuses to write when asked, so the restriction is enforced at runtime, but the /tools display is misleading and cannot be relied on for capability auditing or access verification in automated workflows.
Activity
github-actions commentedon Oct 25, 2026
Thanks for opening this issue and for the clear, detailed reproduction steps! 🙏 It's a great catch that
/toolsis displaying tools (likewrite) that aren't actually available to the agent, making it tricky to verify an agent's real configuration. A maintainer will take a look at this shortly — we appreciate you helping us make the CLI experience more accurate and reliable!AnilMaktala commentedon Oct 26, 2026
Thanks for raising this.
For an agent whose
toolslist contains only"read", the/toolscommand displays awritetag as well. The agent correctly refuses to write when asked, so the restriction is enforced at runtime, but the/toolsdisplay is misleading and cannot be relied on for capability auditing or access verification in automated workflows.Marking this as a bug to investigate further.