What a coding agent needs beyond a model
A coding agent connects a conversation to actions. The model can ask to read a file, change some code, or execute a program. The application has to decide how each request is handled.
Start with inspectable behavior
Workbench now puts the conversation, settings, progress, and tool results in a full-screen terminal interface. New sessions begin in Inspect only mode. The selected project, access level, model, and transcript settings make the scope visible before a run.
An offline preview can exercise the interface without credentials or provider requests. That is a useful way to inspect the interaction, but it is separate from verifying a real model-backed run.
Tools need a clear boundary
In the Workbench project, every file-tool path is resolved against the selected workspace. Resolving symlinks matters: a path that appears to be inside the project can point somewhere else.
That protects the file-tool boundary. It does not turn a Python subprocess into an operating-system sandbox, so execution still requires care about the workspace and code involved.
Errors belong in the conversation
A malformed tool argument should become an understandable tool result. Crashing the program loses the conversation and gives the model no chance to adjust.
The agent loop also has a step limit, request timeouts, and an explicit read-only mode. These are small controls that make a run easier to inspect.
Verification closes the loop
An edit is a proposal until it has been checked. The final response should distinguish between files changed, tests actually run, and anything left uncertain.
The project tests the conversation loop with simulated provider responses. That verifies the local behavior without assuming an external provider is available.