**Bug Description** Feature request: forked commands should name their agent from the task text, like /subtask does Current behavior - A command or skill with context: fork (for example background: true plus agent: ) always gets an agent named after the command. My /fresh command gives fresh, fresh-2, fresh-3… - With several running at once, /tasks and the agent list only show numbered copies of the same name. I can't tell which agent is doing what without opening each one. What I'd like

[Feature Request] Fork commands should derive agent names from task arguments like /subtask does

Status Open

Reported on v2.1.281

Maintainer reply None cached

Activity 0 comments · opened Oct 1, 2026

Bug Description
Feature request: forked commands should name their agent from the task text, like /subtask does

Current behavior

A command or skill with context: fork (for example background: true plus agent: <type>) always gets an agent named after the command. My /fresh command gives fresh, fresh-2, fresh-3…
With several running at once, /tasks and the agent list only show numbered copies of the same name. I can't tell which agent is doing what without opening each one.

What I'd like

Name the agent from the command's arguments, the way /subtask <task> already does: the first three words, lowercased, only [a-z0-9-], at most 24 characters, with -2, -3… added when the name is taken.
For example, /fresh review the auth module for races would give fresh-review-the-auth, or just review-the-auth.
If the arguments are empty, keep using the command name.

Nice to have: a setting in the command file
agent-name: args # name from the arguments, the /subtask way

Why it matters

Background commands with a clean context are useful for sending off several independent tasks at once. Unclear names make these agents hard to tell apart, hard to message, and hard to stop.
/subtask already solves this, so forked commands would just need to reuse the same naming.

Environment: Claude Code 2.1.281, Linux

Environment Info

Errors

[]