APP SUPPORT

Radar Dev Monitor

Local development servers, ports, and processes.

Radar Dev Monitor · Detection and custom tools

How do I write a precise custom tool rule?

Use worked rules to understand alternatives, process prefixes, command matching, and precedence.

In this article

Understand what must match

A custom tool claims a listener when its rule is enabled, its process name begins with one of your Process name entries, and its full command contains one of your Command line contains entries. The comparison ignores letter case. It must also be listening on TCP.

The process and command conditions are both required. Commas express alternatives inside a field. They do not express “and,” and they do not pair the first process with the first command term. For node, bun plus alpha.js, beta.ts, any of the four process/command combinations can match.

Spaces inside a command term stay meaningful. A term such as serve --local checks for that contiguous text. Matching is substring-based, not exact-word matching: api can also match rapid-api.js. python is a prefix and can match python3; it cannot match a name that only contains python later. Asterisks and regular-expression punctuation are treated literally.

Example: give a Node API a specific tool label

Suppose Details shows Executable: node, and its command includes node /Projects/catalog/catalog-api.js --port 4100.

  1. Open Settings… → Detection → Add Custom Tool….
  2. Set Name to Catalog API.
  3. Set Process name to node.
  4. Set Command line contains to catalog-api.js.
  5. Choose an Icon and Color. Check the live verdict, then click Add Tool.
  6. Reopen the panel. A matching listener should use Catalog API as its tool label; its main card name still comes from the project folder.

This rule can replace the broad built-in Node server label because custom rules are checked first. It will also claim another project's Node listener if its command contains catalog-api.js. Choose a more distinctive command term if that is too broad.

Example: recognize the same tool under Node or Bun

Suppose your tool can run as either node catalog-api.js or bun run catalog-api.ts.

  1. Add or edit a custom rule named Catalog API.
  2. Set Process name to node, bun.
  3. Set Command line contains to catalog-api.js, catalog-api.ts.
  4. Save and inspect the server after each usual launch method.

Either process prefix and either command term can match. You do not need the Show unrecognized localhost servers switch on once an enabled rule recognizes the listener. The rule still needs a TCP listener; a one-off script with the same arguments does not become a server card just because it matches the text.

Example: fix an earlier rule that captures everything

Suppose you created General Node first, with Process name node and Command line contains server. Later you create Catalog API with the term catalog-server.js.

The earlier General Node rule matches catalog-server.js first. The Catalog API draft can therefore show no eligible live match despite having correct text.

  1. In Detection, turn off General Node and reopen or recheck the Catalog API editor.
  2. Confirm that Catalog API now has the expected live match.
  3. Edit General Node to use a term that does not overlap this API if you still need that rule.
  4. Re-enable the revised rule and verify both servers in the panel.

Custom rules retain creation order; editing does not move a rule and there is no drag-to-reorder control. Built-ins follow all custom rules, so disabling a specific built-in is usually unnecessary when a correct custom rule already claims the process.

Check the result before relying on it

Start the intended tool using your normal command, open the editor, and check the live verdict. Then save, open the panel, and inspect the card's tool, project path, and command in Details. If you also have another similar server running, inspect its label to check for accidental overlap.

The verdict displays the first matching listener, not a count of every match. It is a preview of recognition; it does not test browser reachability, application health, or stopping. An enabled saved rule can work later even if no server was running when you saved it.

If the editor has no selectable starting row because a built-in already recognizes your tool, use manual fields. If editing an existing disabled custom rule, keep in mind that its disabled state is preserved in the preview and after Save. Enable it from Detection to use it.

Continue exploring

Back to Knowledge Base →Back to Radar Dev Monitor →