Repository navigation
Custom commands with agents should(?) run in isolated sessions #2315
Description
Problem
When using a custom command that specifies an agent, the agent execution happens in the current context/session instead of running in isolation like when using @agent syntax.
Expected Behavior
A custom command like /commit with agent: git configured should behave the same as @git save my work - running the agent in its own isolated session without polluting the current context with tool output.
Current Behavior
The /commit command with agent: git executes everything in the current context/session, showing all git tool output and analysis in the main conversation.
Configuration
Command configuration (command/commit.md):
---
description: Commit using the current git state
agent: git
---
## Context
**Current git status**
!`git status`
**Current git diff (staged and unstaged changes)**
!`git diff --no-ext-diff HEAD | tr @ _`
**Recent commit format**
!`git log --oneline -10`Agent configuration (agent/git.md):
---
description: Create well-formatted commits using the conventional commits style
mode: subagent
permission:
bash:
"git add *": "deny"
"git stage *": "deny"
"git reset *": "deny"
"git restore *": "deny"
---
< git instructions here >Impact
This makes custom commands with agents less useful since they clutter the main conversation instead of providing the clean, isolated execution that @agent syntax provides.
If this is the intended behavior, then perhaps an additional /command property like subtask: <boolean> could allow both behaviors
Activity
NaikSoftware commentedon Sep 1, 2025
It looks like subagent used under the hood. But not showed in the session title
rekram1-node commentedon Sep 1, 2025
wdym? can you reword that
NaikSoftware commentedon Sep 1, 2025
I tried to ask which agent currently used and it responds with name of subagent
rekram1-node commentedon Sep 1, 2025
ah it is probably lying, the agent doesnt know its name but it does know the name of other subagents so it is just telling you the name of a subagent it can trigger
arsham commentedon Sep 10, 2025
You can test this behaviour by running the slash command and instruct it to do nothing and return back. Then in the current context ask questions about specific instructions in the slash command. Unfortunately my tests shows that the context is not isolated.
NaikSoftware commentedon Sep 10, 2025
It worked for me, because I copied slash commands from Claude Code. There I described at the beginning of the instructions which agent to use. I this case calling /my-command always switch to isolated agent, but this is a tricky 😄
arsham commentedon Sep 10, 2025
I don't think that is what this issue is about, correct me if I'm wrong. You can delegate to agents in the instructions, but the issue is about the part in the front-matter:
In this setup, we expect the command to be run by the
gitagent and in isolation.rekram1-node commentedon Sep 10, 2025
if it is a subagent I think that makes a lot of sense, but what if it's a primary agent?
arsham commentedon Sep 10, 2025
I think it would be valuable to have both behave the same and in isolation. When we set this
agentin a slash command, we intend to isolate it, otherwise we would omit theagentall together.Another possibility would be in cases someone wants to run the command in the context of a certain primary agent. In that case we can document that they could use shift-tab to choose the primary agent and run the command with it.
audibleblink commentedon Sep 10, 2025
If the slash command has no configured subagent, then I think it's a reasonable expectation for it to run in the currently selected agent and context.
In the event that someone wants the slash command to run with the currently active main agent, but as a subtask to strategically separate context, then a
subtaskfrontmatter property seems valuable.rekram1-node commentedon Sep 13, 2025
Will be in next release, will behave as @audibleblink said
feat(integrations): `iris integrations health` and `test <type>`