If I stop a command, I usually mean that command. I have not necessarily changed my mind about having a terminal.

That small distinction became part of the September work on Neuron, the local coding workbench I am building. It connects projects, source changes, tasks, agent runs and their evidence. The terminal is one tool inside that larger workflow.

It needed to be useful enough to work in, with controls that described what they actually changed.

One control cannot explain every kind of stop

In the recorded September 4 build, Terminal is off by default. Turning it on makes availability a persistent app preference. It remains available across project changes and restarts until the user turns it off.

While a command runs, Stop command cancels that operation. Turn off terminal changes the capability's availability. Those actions occupy different scopes, and the interface gives them different controls.

This sounds almost too ordinary to write about. That is why it interests me. A workbench can have elaborate agent orchestration and still make an ordinary action surprisingly difficult to interpret.

When a button changes more than the person expects, the next question becomes “what state am I in now?” The work has acquired a second task: figuring out the tool.

The selected project is a starting directory

The direct terminal inherits the user's operating-system environment. The chosen project sets its starting directory; it does not create a filesystem sandbox.

That boundary needs to be clear near the feature. A project label alone can suggest a stronger restriction than the implementation provides.

Neuron also has a separate catalog of named checks. Those have their own scope and execution constraints. Treating the direct terminal as just another item in that catalog would conceal a meaningful difference in authority.

Once enabled, the direct terminal runs commands without asking for the same approval each time or imposing an artificial timeout. That was a deliberate choice for an interactive power tool. It makes the initial explanation and the persistent on/off state more consequential.

Persistence should preserve the decision the person made

The preference survives a restart. A running operation and its result have their own lifecycle. Navigating somewhere else in the workbench is another separate action.

Keeping those states distinct makes it possible to answer useful questions: Is Terminal enabled? Is a command running? What happened to the last attempt? Which project directory will the next command start in?

The audit record stores hashes rather than command and output text. That is another boundary to describe accurately: an audit entry does not mean a full transcript is retained there.

I want a person returning to the workbench to be able to read those answers from the product, without reconstructing them from a chat.

What we actually checked

The September 4 record includes eleven passing Studio runtime cases covering behavior such as direct execution, preference persistence across runtime reconstruction and explicit off/stop control. A standalone smoke walkthrough also turned Terminal on, ran a command and turned it off in a disposable workspace.

Those observations support the implementation described here. They do not establish that a new user will understand every control without help. Neuron remains a local release candidate, and an observed user task test is still open.

For a similar feature, I would write down the scope of each control before polishing its label. Then walk through enable, run, stop, navigate, restart and disable. At each step, name what persists and what changes. If the label promises something the state cannot demonstrate, fix that mismatch while it is still small.

Record and method

Written September 6, 2026, from Neuron's September 3–4 workbench record and the current terminal control source. AI assisted with drafting. This describes a verified local build, not a public terminal service or an available download. The Neuron overview records the project's wider scope and remaining work.