Checkpoint: One Mental Model for Reasonix

Reasonix’s central promise becomes concrete when one proposed edit encounters several owners of authority. This synthesis connects the model’s choices, the host’s gates, the tool’s effects, and the state that remains afterward. The practical result is a way to judge a turn: you can ask what the user decided, what the model proposed, what the host allowed, what the tool actually did, and what is still unknown.

That distinction is more useful than calling a run simply “autonomous” or “safe.” Reasonix is designed so autonomy can continue inside boundaries, but each boundary answers a different question. The model chooses useful work. The user sets the objective and can reserve decisions for themselves. The host controls execution and records observations. The tool or external capability returns an effect, an error, or a refusal. A normal stop, a Plan pause, and a continuing Goal are therefore different outcomes rather than different grades of success.

One request, several owners

Take a concrete request: update a deprecated logging library, change the affected code, run the project’s tests, and do not publish anything. The user has supplied an objective and a meaningful constraint. The model now has to decide how to investigate. It might inspect the dependency declaration, search for old imports, compare usages, and propose an edit. Those choices belong to the model’s reasoning process. Reasonix does not hardcode the exact sequence for every repository.

But a model choice is not yet an authorized effect. When the model asks to read or edit a file, the host resolves the tool name and arguments, validates the request, and classifies the concrete effect. A read and a write may use related tools, but they do not carry the same consequence. If the call is behind a proxy, the host checks the resolved target rather than trusting the wrapper’s surface description. If an extension changes the call, the replacement is validated again before it reaches the execution boundary.

Next comes the permission decision. A deny rule blocks the call. An ask rule sends it to the user when an approver is available. An allow rule authorizes a matching subject, and the fallback depends on whether the call is read-only or a writer. The same file-writing tool can therefore be treated differently depending on its path, and a move can be judged against both of its endpoints. The result is not a single permanent label such as “the model is trusted”; it is a decision about this call.

Only after that decision can the host coordinate the workspace and apply the Sandbox. A permitted file writer still has to remain within the approved roots, with path traversal and symlink escapes rejected. A command can be inside the workspace and still be denied because its shell form is risky or explicitly blocked. The host may acquire a write lease or run an approved hook only after the earlier gates have allowed the operation. This ordering keeps a blocked request from holding the resource that another operation needs.

The tool then returns an outcome. It may report that the edit succeeded, that a test failed, or that the call could not execute. The host records what it can observe and sends a bounded result back to the model.