Settings

Project Settings > Plugins > HullForge.

Port

Default 8765. The loopback port the editor listens on.

This is set in the editor, not in Claude. There is deliberately no port field in the Claude connector, and looking for one is a reasonable thing to do, so it is worth saying why there isn’t one.

The connector does not need to be told the port. Each editor writes the port it actually bound into its session file, and the connector reads that. Two settings that could disagree would create a whole class of confusing failure: the editor listening on one port, the client configured for another, and nothing on screen to indicate which is wrong. One source of truth removes that entirely.

A consequence worth knowing: changing the port here needs no change anywhere else. Not in Claude, not in a config file. The editor rebinds, rewrites its session file, and the connector picks it up on its next call.

Setting it to 0 makes the operating system pick any free port, which is the most robust option when several editors are open at once. Discovery works identically, so there is nothing to collide.

Reasons to pin a specific port: a firewall rule, another application already holding 8765, or a policy about which loopback ports may be bound.

Changing the port rebinds immediately. No editor restart.

If the connector cannot find your editor

Discovery is the only supported path, so the problem is the session file rather than a missing setting. Check, in order:

1. Ask Claude for the bridge status. It reports which registry directory it is reading and what it found there.
2. Confirm %LOCALAPPDATA%/HullForge/sessions/ exists and holds an entry for your project. If that directory cannot be written, the editor logs a warning at startup saying so.
3. Confirm the process id in that entry matches your running editor. Stale entries are ignored on purpose and swept at the next editor start.

See Connector troubleshooting.

Start Automatically

Default on. The bridge begins listening as the editor loads.

Turn it off if you would rather start it by hand, then use the console:

HullForge.Start
HullForge.Stop
HullForge.Status

Game Thread Timeout

Default 60 seconds. How long a single tool call may occupy the game thread before it is abandoned.

The right value is workload-dependent. A landscape import legitimately blocks for minutes, while an unresponsive editor during ordinary work should surface quickly rather than hang the client. Raise it if you routinely do heavy imports; lower it if you would rather find out sooner that something is wedged.

Catalog mode

Default off. Lists only a core handful of tools until you switch an area on, with an area list beside it for the ones to start with.

This is a connector behaviour configured here, which is deliberate. The alternative is a setting on the Claude side that can disagree with this one, and two settings that can disagree produce a class of failure with nothing on screen to say which is wrong. It is the same reasoning as the port.

Changing it rewrites the session file without rebinding the socket, so a live connection is not dropped and the connector picks the change up on its next call. No editor restart, no client restart.

HULLFORGE_CATALOG_MODE in the connector’s environment overrides this when it is set, including when it is set to 0, so one person can get every tool back without editing a project setting that gets committed. Full detail in Catalog mode.

How clients find the editor

You do not configure a host or a port anywhere on the client side. Each running editor advertises itself in two places:

File	Purpose
<project>/Saved/HullForge/session.json	Project-local, useful when debugging
%LOCALAPPDATA%/HullForge/sessions/	User-global, how clients discover editors

Both hold a port, a random session token, the project name and path, and a process id. Both are removed when the editor closes, and entries left behind by a crash are swept on the next startup.

This is why several projects can be open at once, and why nothing needs restarting when you open or close one.