Troubleshooting
Confirming that a Session is Running
The server listens on port 50505. To confirm that the listener is up:
ss -ltnp | grep 50505
If the command returns nothing, no RPC-enabled session is running.
A listening port shows that the session was started correctly, but not that it accepts commands. To confirm the session end to end, send it one:
/path/to/Coreform-Cubit-2026.8/bin/cubitc -c "brick x 10"
The command is executed in the running session exactly as though it had been typed into the GUI command panel. A working session responds:
Successfully created brick volume 1
Journaled Command: brick x 10
The new volume appears in the GUI. Delete it, or use the Reset command, before returning to work.
If a session responds to commands sent this way but not to your agent, the problem lies in how the agent is invoking the client rather than in the session itself. To pursue that further, the cubitc client can be used interactively: starting it with the --repl option opens a command prompt against the running session, in which Cubit commands can be entered directly. Anything that works there and fails through the agent is an agent problem.
Common Problems
| Symptom | Cause and remedy |
|
Nothing is listening on port 50505. |
The GUI may not have started with RPC enabled. Confirm you launched ./coreform_cubit -rpc with the leading ./, from the installation root — a bare coreform_cubit may resolve through PATH to a different installation. Confirm the installation is 2026.8 or later. |
|
-rpc was accepted but no port opened. |
-rpc is silently ignored when combined with -nogui. The RPC server lives in the GUI application and requires a display. |
|
The session responds to commands you send yourself, but not to the agent. |
The problem is in how the agent is invoking the client rather than in the session. Confirm that it is using the full path to bin/cubitc, and that it is invoking the script directly rather than by way of a python prefix. |
|
The agent reports that a command returned false, or that it produced no error and no result. |
Python source was sent to the session instead of a Cubit command. Only Cubit commands and named RPC methods execute over RPC, and Python fails silently rather than reporting an error. |
|
A long meshing operation is reported as failed although it succeeded. |
The client waits 60 seconds for a command to complete. Raise --command-timeout for long operations, and be aware that an agent may read the timeout as a failure and retry. |
|
The agent is working very slowly on an operation covering many entities. |
Each command is a separate exchange with the session. Large batch operations are slow by construction; the GUI shows them arriving one command at a time. |
|
Geometry appears in the model that you did not create. |
Another client — an agent, a second terminal, or the GUI command panel — is connected to the same session, or an agent retried a command after an ambiguous result. |
|
You are unsure which Cubit session a client is connected to. |
Identify the process holding the listener, then the terminal that started it. |
Identifying the Session behind Port 50505
When more than one Cubit session may be running, or when you are unsure which one a client reached:
ss -ltnp | grep 50505
ps -o ppid,tty,lstart,cmd -p <pid>
The first command reports the process holding the listener. The second, given that process ID, reports which terminal started it and when.