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
Naming feedback: "agent view" conflates with the existing "agent" concept #59846
"Added agent view (Research Preview): a single list of every Claude Code session — running, blocked on you, or done."
But "agent" already has a specific, distinct meaning elsewhere in Claude Code:
The Agent tool / subagent_type parameter
.claude/agents/*.md definitions
The Claude Agent SDK
In those contexts, an agent is a configured role — a system prompt + tools + model + permissions. It's the thing, not the run.
What "agent view" actually shows is the list of sessions — the changelog itself calls them sessions in the same sentence ("a single list of every Claude Code session"). The in-app hint reinforces the split: "Press the left arrow from any session or run claude agents from the terminal to open agent view."
So within one feature, the same concept is called both "session" (in description) and "agent" (in the view name + CLI command). And in the wider product, "agent" already means something else entirely.
Suggested rename
Either of these would disambiguate:
Session view / claude sessions — most precise; already how the changelog describes the contents
Chats / claude chats — friendlier; matches how users describe the thing ("my other chat")
"Agent" should stay reserved for the configured-role concept (Agent tool, .claude/agents/, SDK).
Impact
Minor on its own, but it's the kind of naming choice that compounds — every doc page, error message, and community post that says "agent" now has to clarify which kind. Easier to fix while the feature is still in Research Preview.
+1 to the rename. The "agent" overload is going to keep producing user-facing confusion for the same structural reason naming collisions usually do: the new feature is named after the surface it sits on, not the noun it represents.
Concretely:
Agent tool / subagent_type / .claude/agents/*.md / Claude Agent SDK → all refer to a configured role (system prompt + tools + model + permissions). This is a type; many instances of this type can exist; they have no identity until invoked.
"Agent view" (v2.1.139) → shows sessions (running, blocked-on-you, done). This is an instance; each one has identity, state, lifetime, and a position in the user's attention queue.
These are different categories — type vs instance — and conflating them costs users twice:
At discovery. Users who look up "agent" in docs to find their session-list will land on the SDK / .claude/agents/ material first, because that's the older, denser concept. They have to know to dig past it. New-user friction.
At operation. Users describing a problem ("my agent froze") now have to disambiguate which sense they mean — the configured-role one or the session-list one — and tooling that grep's transcripts/issues for agent returns a less-signal-dense set than it used to. Documentation-grep tax.
The two suggestions in the OP both fix the type/instance split, but they hit different language registers:
"Session view" / claude sessions — the precise, technical name. The changelog text already uses session in the same sentence ("a single list of every Claude Code session"), so internal naming already disagrees with itself; renaming to "session view" actually aligns the surface with how the docs describe the contents.
"Chats" / claude chats — the user-facing name. Aligns with how users naturally describe the thing ("my other chat", "switch chats"). Lower precision but better discoverability and matches the mental model from other coding-assistant UIs.
If shipping one, I'd argue for claude sessions as the canonical command + "Session view" as the in-app label, with "Chats" optionally usable as a friendly alias in the help/onboarding copy. That preserves the unambiguous mapping to ~/.claude/projects/**/*.jsonl (which Anthropic already calls "sessions" at the filesystem layer) and reserves "agent" exclusively for the configured-role concept.
The cost of doing this rename is small now (one release behind the agent-view ship) and grows monotonically — every downstream tool (claude agents CLI, agent-view docs, third-party schedulers and dashboards) that integrates against the current name makes the rename more expensive. The window where this is cheap closes fast.
One additional risk worth naming explicitly: the existing claude agents CLI command (which lists configured roles per ~/.claude/agents/) was already a slight naming collision with .claude/agents/*.md and the Agent tool; the agent-view rebrand has now made claude agents ambiguous in a third direction. If this thread results in claude sessions shipping as the session-list command, it would be worth also taking the cycle to clarify whether claude agents continues to mean "list configured roles" (which is what it does today) or gets repurposed — because the current state is that claude agents is the CLI command most likely to be misread under either naming.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
Activity
kcarriedo commentedon May 17, 2026
+1 to the rename. The "agent" overload is going to keep producing user-facing confusion for the same structural reason naming collisions usually do: the new feature is named after the surface it sits on, not the noun it represents.
Concretely:
Agenttool /subagent_type/.claude/agents/*.md/ Claude Agent SDK → all refer to a configured role (system prompt + tools + model + permissions). This is a type; many instances of this type can exist; they have no identity until invoked.These are different categories —
typevsinstance— and conflating them costs users twice:.claude/agents/material first, because that's the older, denser concept. They have to know to dig past it. New-user friction.agentreturns a less-signal-dense set than it used to. Documentation-grep tax.The two suggestions in the OP both fix the type/instance split, but they hit different language registers:
claude sessions— the precise, technical name. The changelog text already uses session in the same sentence ("a single list of every Claude Code session"), so internal naming already disagrees with itself; renaming to "session view" actually aligns the surface with how the docs describe the contents.claude chats— the user-facing name. Aligns with how users naturally describe the thing ("my other chat", "switch chats"). Lower precision but better discoverability and matches the mental model from other coding-assistant UIs.If shipping one, I'd argue for
claude sessionsas the canonical command + "Session view" as the in-app label, with "Chats" optionally usable as a friendly alias in the help/onboarding copy. That preserves the unambiguous mapping to~/.claude/projects/**/*.jsonl(which Anthropic already calls "sessions" at the filesystem layer) and reserves "agent" exclusively for the configured-role concept.The cost of doing this rename is small now (one release behind the agent-view ship) and grows monotonically — every downstream tool (
claude agentsCLI, agent-view docs, third-party schedulers and dashboards) that integrates against the current name makes the rename more expensive. The window where this is cheap closes fast.One additional risk worth naming explicitly: the existing
claude agentsCLI command (which lists configured roles per~/.claude/agents/) was already a slight naming collision with.claude/agents/*.mdand theAgenttool; the agent-view rebrand has now madeclaude agentsambiguous in a third direction. If this thread results inclaude sessionsshipping as the session-list command, it would be worth also taking the cycle to clarify whetherclaude agentscontinues to mean "list configured roles" (which is what it does today) or gets repurposed — because the current state is thatclaude agentsis the CLI command most likely to be misread under either naming.github-actions commentedon Jun 16, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Aug 19, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.