Claude Code Agents View: What You Can't See

The word "agent" has been doing a lot of heavy lifting in AI marketing copy lately. It implies autonomy, initiative, judgment. What it usually means in practice is: a model executing a scoped task inside a pipeline you still have to design, prompt, and babysit. Knowing the difference matters—not because the tools aren't genuinely useful, but because people who think they've delegated to something autonomous tend to pay less attention to what it's actually touching.

Claude Code's new Agents View is a real capability upgrade. It's also a good case study in what happens when the dashboard abstraction gets ahead of the visibility your security posture actually requires.

The dashboard shows you less than you think

In a recent walkthrough by the Software Engineer Meets AI channel on YouTube, the presenter demonstrates spinning up a parent agent with this prompt: run two sub-agents, one to fetch the Claude Code changelog, one to fetch the news page. The parent agent spawns two child processes. They go off and do their work. Back on the main dashboard, you see one entry. No indication of the sub-agents. No count. No activity log.

The presenter flags this directly: "I wanted to show you that in the new UI, you cannot see how many sub-agents is running. We can see it's working. We don't know that it uses sub agents inside."

That sentence is doing a lot of work. In this demo, the sub-agents are fetching public web pages—low stakes, easy to reason about. But the same architecture that fetches a changelog can fetch your codebase, query internal APIs, read environment variables, or interact with services that have credentials attached. The question isn't whether this demo is dangerous. It's whether the visibility model the dashboard establishes is adequate for the ways people will actually use this tool.

The answer, right now, is no—and that's worth understanding before you build workflows that depend on it.

What "delegation" actually means here

There are two ways to kick off sub-agents in Agents View. You can prompt a parent agent to spawn children, as in the demo above. Or you can trigger a sub-agent directly from the CLI—the walkthrough shows a --bg flag used to background a task ("what is this repo about"). Per the demo, this also surfaces in the Agents View as a new entry. (Note: the --bg flag behavior shown here is from this walkthrough; verify the current flag syntax against Anthropic's official Claude Code documentation before relying on it in production.)

Either way, you're delegating to a process you can't directly observe from the main interface. Inside any given agent, you do have access to a full Claude session—you can see the conversation, change the model, tag specific files. The opacity is specifically at the orchestration layer: the parent dashboard doesn't surface what's happening inside child sessions.

That's an architectural choice. You can debate whether it's the right one for developer ergonomics. From a security standpoint, it means you need to think about what you're authorizing at the prompt level, not just at the interface level—because the interface isn't going to tell you what happened.

The permission moment you should not skip

The walkthrough shows one explicit checkpoint that's actually worth calling out: when the parent agent tries to fetch an external URL, Claude Code asks for permission. "It asks me to fetch this website. Let's allow it," the presenter says, and clicks through.

That permission prompt is the clearest visibility signal in the entire demo. It's also easy to train yourself to click past, especially if you're running complex pipelines where interruptions feel like friction.

Don't. That prompt is you seeing the surface area. Every external request your agent or sub-agent makes is a data exposure boundary—something is leaving your local environment and touching the network. When you're running sub-agents you can't observe from the dashboard, those permission prompts inside the parent session are your primary audit trail for what actually happened.

If you're building workflows that run automatically or unattended, think carefully about what you've pre-authorized and what access your environment provides. An agent that has read access to your codebase, network access to external services, and sub-agents you can't observe from the top level is not a tightly scoped tool. It's a broad delegation.

Local session storage: the privacy feature hiding in plain sight

Here's where the architecture does something right that the demo presents as almost incidental. All sessions are saved locally—on your machine, not in Anthropic's cloud. When the presenter notes this, it's framed as a persistence feature: you can close your terminal, run claude resume --all (shown in the demo; verify against current documentation before using), and pick up where you left off.

But "saved locally" is also a data residency statement. Your sessions—which may contain code, proprietary context, internal API responses, whatever your agents touched—stay on your machine. That's a meaningful privacy property for anyone working with sensitive codebases, and it's worth understanding as a deliberate architectural choice rather than just a workflow convenience.

The flipside: local storage means local exposure. If your machine is compromised, your session data is accessible. There's no remote backup, which is either a privacy feature or a fragility, depending on your threat model. If you're running long, complex agent sessions on work hardware, know where those files live and what's in them.

This is the trade-off in plain language: you get data locality and privacy at the cost of resilience and recoverability. That's not a bad trade—it's just one worth making consciously.

How to use this without flying blind

None of this is a reason to avoid Agents View. It's a reason to use it with a working mental model instead of the one the marketing copy implies.

A few concrete things:

Before you run a multi-agent session, write down what you're authorizing. Not in a compliance-theater way—just literally: what data does this agent have access to? What services can it reach? What would a sub-agent need to touch to complete this task? If you can't answer that, you're not ready to run the task unattended.

Treat permission prompts as information, not friction. When Claude Code asks if it can fetch a URL or access a resource, that's a visibility window. Read it. If the URL or resource surprises you, that's worth investigating before you click allow.

Check inside agents after complex runs. The main dashboard won't tell you what sub-agents ran. Clicking into individual agents gives you the full session view. Do that after any run where the scope wasn't tightly defined.

Know what --bg flag tasks can access. If you're triggering background sub-agents from the CLI, those sessions run with the same environment access as your foreground session. That's not a bug, but it's worth being aware of.

Match your session contents to your machine's security posture. If you're working with sensitive codebases on a machine that's regularly on untrusted networks, understand what your local session files contain and whether full-disk encryption is on.

The Agents View is genuinely useful infrastructure for anyone running complex Claude Code workflows. The visibility gap at the orchestration layer is a real design limitation, not a manufactured threat. It means the tool is asking you to reason about authorization at the prompt level—which is exactly the kind of thinking that separates people who use powerful tools well from people who get surprised by them.

The word "agent" will keep implying more autonomy than it delivers. The question is whether you're the one keeping track of what it's actually doing.

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.