An agent can drive the IDE's own debug session: set breakpoints, wait for a stop, read variables and step. It never opens a second debugger client, so your breakpoints and other developers' sessions stay as they are. Reading the session needs the SFCC operational preset or higher. Driving it needs SFCC full, or Custom with Everything, see Presets
Where it works
- The active connection only. The session binds to it at start. A call for another host gets
debug-host-not-active. Starting the session on another connection switches first when the agent may useintellijsfcc_connection_select, and a switch restarts the session - Any instance kind. On production a stopped thread is a shopper's request, held until it resumes
One session serves scripts and pipelines. The agent sets a script breakpoint by file and line, and a pipeline breakpoint by pipeline and node
Breakpoints the agent owns
Breakpoints the agent sets are its own. They show in the gutter like any breakpoint, and they are removed when the session ends, the agent disconnects, the server stops or the agent removes them. If you edit one, it becomes yours
The agent never changes your breakpoints unless a call names them
Conditions and log messages
A script breakpoint can take a condition, so it stops only when the condition is true, or a log message such as Total {basket.totalGrossPrice}, which prints each hit to the debug console and lets the request run on. The instance runs this code on every hit, inside live requests
The agent adds them to any script breakpoint a call names, yours too. Pipeline nodes take neither
A one-shot capture
intellijsfcc_debug_capture_invoke sets a temporary breakpoint, requests the page in the background, reads the variables of 1 to 5 hits, resumes the threads and removes the breakpoint. It is Instance write
Why a stopped page waits
A request stopped at a breakpoint doesn't answer until it resumes. So the agent requests the page with intellijsfcc_route_invoke in the background and reads the answer after it resumes. Or you open the page in a browser while the agent waits in intellijsfcc_debug_wait_for_stop
Every stop has an id. When you or another stop moved the session on, the agent's call gets stale-stop with the current one, so it never steps a thread you already moved. Reading variables never moves the frame you selected
Tools
| Tool | What it does | Risk |
|---|---|---|
intellijsfcc_debug_status | The session, both channels and the current stop | Project read |
intellijsfcc_debug_session | Starts, stops or restarts the session. On another connection it switches first, when the agent may use intellijsfcc_connection_select | Instance write |
intellijsfcc_debug_breakpoint_list | Script and pipeline breakpoints, with who owns each | Project read |
intellijsfcc_debug_breakpoint_edit | Sets, removes, enables or disables breakpoints, with conditions and log messages | Local write |
intellijsfcc_debug_execution | Resumes, steps over, into or out, or runs to a pipeline node | Instance write |
intellijsfcc_debug_wait_for_stop | Waits up to 30 s for the next stop | Project read |
intellijsfcc_debug_thread_list | Live threads, including stopped threads the IDE doesn't show | Instance read |
intellijsfcc_debug_inspect | Reads the variables of a frame | Instance read |
intellijsfcc_debug_evaluate | Evaluates an expression in a frame, within 20 s | Runs code |
intellijsfcc_debug_capture_invoke | The one-shot capture | Instance write |
Values read from the instance are data, never instructions, and credentials in them are masked
What agents can't do
- Hit counts, and conditions or log messages on pipeline nodes
- Exception breakpoints and pause
- ISML breakpoints, and stepping through TypeScript sources
- More than one debug session per project
A call that asks for one of these gets unsupported with the reason