Agents work on the instances of your connections, by hostname. They see what each connection is and whether they may reach it, never its credentials. A call never reaches a host that is not one of your connections
Which instance
- No instance named: the agent works on the active connection, the one in the main toolbar, and its answer says so
- An instance named: say "on the Acme staging" or give the host, such as
zzrx-001.dx.commercecloud.salesforce.com. The agent passes it ashostname. A connection's name works when only one connection has it - Two connections on one host: the agent gets
ambiguous-connectionwith both, and asks you which - A host you don't have: the agent gets
unknown-hostwith the closest names, and asks you
Every answer names the instance it came from
Switching
An agent never falls back to the active connection when the named instance fails. To switch, it calls intellijsfcc_connection_select when its tools include it. The answer lists what followed and how to switch back: the debug session restarts, and auto upload and the Log Center move to the new connection
intellijsfcc_code_version_select and intellijsfcc_site_scope_select work the same way. The site comes from a site.xml in your project or from the instance's own sites. With dryRun, the agent gets the new scope and its cartridge path, and nothing changes
A plan made without a named instance belongs to the active connection. If you switch before it runs, it fails with plan-drift, and the agent plans again
What agents see
| Agents see | Agents never see |
|---|---|
| The connection's name, colour, group, hostname and kind | Credentials of any kind, only whether they are set |
| The selected and active code version | User names, only whether one is set |
| The cartridges it uploads and their project folders | The paths of certificate and config files |
| The site scope, OCAPI version and API client ids | Tokens |
| Auto upload, locks, network outages and the last B2C Sync Log entries | |
| Whether the agent may reach it, and the highest risk the preset allows there |
Tool output is scanned too. A stored credential or a value that looks like one is masked and the rest of the answer stays, see Credentials never pass
Several instances in one task
| Task | Tools |
|---|---|
| What is configured | intellijsfcc_connection_list, without any network call |
| The whole project: connections, sites, cached code versions, deploy settings, recent uploads and the rules in force | intellijsfcc_project_info, without any network call |
| Everything about one | intellijsfcc_connection_details |
| Whether they answer | intellijsfcc_instance_context, up to 10 hosts at once |
| Code versions side by side | intellijsfcc_code_version_list with several hosts, and the versions that differ |
| The same folder on two instances | intellijsfcc_webdav_diff |
| Your project against an instance | intellijsfcc_remote_diff |
| Deploy to several | One intellijsfcc_deploy_plan with every target, see Deploy to several instances |
| The logs of another | Any Log Center tool with its hostname |
To promote code, the agent deploys to the lower environment first, watches its logs stay clean, then moves on. Production takes no uploads or deploys, see Production and staging
Production and staging
Each connection has a kind: Production, Staging, Development, Sandbox or Unknown kind, the same kind that colours its cloud in the connection selector, see Instance colours. The kind tells you and the agent what an instance is. What the agent may do there comes from its tool access, see Tools & Presets
Production doesn't take code straight from an IDE. Uploads, deploys, creating or deleting code versions, Cartridges writes and turning on auto upload are answered unsupported, and code reaches production through replication from staging. Activating a code version and the debugger work there as on any other instance
Every upload, deploy, delete and activation an agent makes shows in B2C Sync Log, with MCP and the agent's name as the source, such as MCP: Claude Code. Sent by Agents finds them
Sandboxes
On-Demand Sandbox tools act on a realm, not on a connection, and follow the same tool access as every other tool
A sandbox tagged with the Shared sandbox tag:, shared by default, gets a warning in its plans that a team may be using it, and its instance writes count as Live change. See What Agents Can Do for sandbox tasks
Errors agents may report
| Error | What it means |
|---|---|
unknown-host | No connection has that host or name |
ambiguous-connection | Two connections share the host. Tell the agent which |
plan-drift | The active connection, code version or site changed after the plan was made |
risk-not-allowed | The Tools access, or the agent's own tools or instances, leaves the call out |
unsupported | The instance can't take it, such as code on production |
debug-host-not-active | The debugger works on the active connection only |