Claude Code Is One Tool With Four Different Personalities
- Sangamesh Gella
- Nov 12, 2025
- 5 min read
Updated: Feb 18
I spent some days bouncing between Claude Code environments. I used the CLI on my Mac, the web interface in my browser, and did quick checks on my iPhone while grabbing green tea.
Same AI. Same repo. Wildly different experiences.
At first, I thought something was broken. Why does the web version feel so... different? Where are my slash commands? Why does the CLI give me more control, but the web lets me run five things at once?
Then it clicked.
Claude Code isn't one tool trying to be everywhere. It's four distinct personalities optimized for different contexts. Once you stop expecting them to behave the same, you start using them correctly.
The Four Personalities of Claude Code
CLI: The Power User
This is where Claude Code started. Terminal-first. Command-driven. Full control. You get slash commands, complete customization, and the ability to configure everything exactly how you want it. The AI runs on your machine, with your permissions, and interacts with your actual files.
It's sequential. One task at a time. Deep focus. If you're doing complex refactoring, chasing down a gnarly bug, or need to shape exactly how the agent thinks, the CLI is your home base.
Web: The Parallel Executor
Open your browser. Connect your GitHub repos. Kick off five bug fixes at once. The web interface runs everything in isolated cloud sandboxes. Each task gets its own environment. They don't interfere with each other. You can monitor all of them from a single screen.
But here's the tradeoff: no slash commands. The interface is cleaner, more visual, and less granular. You're delegating work, not directing every move. This setup is perfect for clearing bug backlogs, making backend changes that need tests, or addressing questions about code architecture. It's ideal for tasks where you want Claude to work independently while you handle something else.
IDE: The Integrated Partner
Claude Code extensions for VS Code and Cursor IDEs integrate directly into your editor. You get the same intelligence as the CLI, but the context is your current file, your current line, and your current thought. It feels less like calling an agent and more like pair programming.
You're not switching contexts. You're staying in flow. The AI integrates into your existing workflow rather than asking you to adapt to its interface.
Mobile: The Observer
The iOS app is in early preview and limited. You're not doing heavy development here. Instead, you're monitoring sessions you started elsewhere, steering an agent that's already running, checking status, and kicking off small, well-defined tasks.
I've used it to review PRs during commutes, to start a fix while walking to a meeting, and to check if that parallel execution finished while I was away from my desk. It's not about coding on your phone; it's about staying connected to work that's happening in the cloud.
The Network Access Paradox
Here's where it gets interesting. When Claude Code runs on the web, you choose a network access mode. There are three options: Limited, Custom, or None.
Limited means Claude can only reach pre-approved domains like the NPM registry, PyPI, and Docker Hub. This is a safe default.
Custom means you define exactly which domains the agent can access, including your internal APIs, company docs, and specific external services.
None means Claude is completely offline. It works only with what's already in your repo.
Same prompt, different network mode, different results. I asked Claude to implement OAuth in a test project. On my laptop's CLI with full network access, it pulled the latest library and used modern patterns. On the web with limited access, it couldn't fetch that library, so it wrote a more manual, self-contained implementation.
Not wrong. Just different. The environment shaped the solution.
The Salesforce Parallel
If you work in Salesforce, this should feel familiar.
Parallel execution on the web? That's batch processing patterns. You can spin up multiple jobs and let them run independently. Check back for results later.
Network access modes? That’s similar to Remote Site Settings and Named Credentials. You control which external systems your code can reach.
Sandbox isolation? Think of Salesforce sandboxes. These are isolated environments where changes don't touch production.
Real-time steering? This is akin to flow debugging. You can watch it run and adjust mid-execution.
The architecture isn't alien. It's just applied to AI agents instead of Apex classes and Flows.
Match Tool to Task
The mistake I made early on was treating all four environments as interchangeable. They're not.
Use CLI when you need complete control. This is ideal for complex refactoring, custom workflows, and deep debugging sessions where you're shaping the agent's thinking.
Use the web when you need parallel execution. This is perfect for bug backlogs, routine fixes, and backend changes. It’s for tasks where you want multiple independent tasks running at once.
Use IDE extensions when you're already in flow. This is great for quick edits, context-aware suggestions, and pair programming moments.
Use Mobile when you're away from your desk but need to stay connected. This is suitable for monitoring, quick reviews, and status checks.
Stop expecting one environment to do everything. Start choosing the right personality for the job.
The Accessibility Tax
Here's the uncomfortable truth: making something more accessible often means taking power away. The web interface removed the terminal barrier. Anyone can click a button and connect a repo. No command-line skills are needed. But it also removed slash commands, full customization, and the granular control that makes CLI so powerful.
That's not a bug. It's a design choice.
Anthropic explicitly stated that the CLI will remain the most intelligent and customizable interface. Web and Mobile are about meeting developers wherever they are. Accessibility and power live on opposite ends of the spectrum. You can optimize for either one, but rarely both.
The Convergence Story
OpenAI launched Codex five months before Claude Code on the web. They share nearly identical architecture. Both feature cloud execution, parallel tasks, and browser and mobile access. When two leading AI labs land on the same design, it’s not a coincidence.
This is the shape of where this is going. Agentic AI doesn't live in one place. It adapts to context. Terminal for power users, browser for accessibility, mobile for monitoring, and IDE for flow. The future isn't one universal interface. It's context-aware tools that behave differently depending on where and how you're working.
What This Means for You
If you're using Claude Code, stop bouncing between environments expecting consistency. Start choosing the right one for your task.
If you're building agentic workflows for Salesforce, pay attention. The patterns here map directly to automation architecture. Think about sequential vs. parallel, restricted vs. full access, and deep control vs. broad delegation.
If you're watching this space, notice the convergence. This multi-environment, context-aware approach isn't unique to Anthropic. It's becoming the standard.
The tool doesn't change. The context does. And that changes everything. Below is a video sharing the same perspective and how it helped me with Salesforce Development.
If the same AI produces different results based purely on which environment it's running in, are you optimizing for the right environment, or just using whatever's convenient?
Read more about Claude Code on the Web here.
P.S. If you are reading this, you will definitely find it helpful. I write about Salesforce, AI tools, and productivity stuff that actually works: no fluff, no generic advice, just real experiences from the trenches. For more information, visit my website's home page below and subscribe if you haven't yet. Thank you for reading this.
Comments