KoboldCpp 1.123 makes agent approvals depend on the tool and workdir

A local coding agent can revise a copied runbook without needing permission to execute every command on your workstation. KoboldCpp 1.123, released October 13, 2026, makes that distinction more explicit: its auto confirmation mode treats file work inside the working directory differently from shell calls and writes outside it.

The release also adds per-tool approval settings and saved sessions. Those features are useful together, but they mean the global mode is no longer enough to explain what the agent can do. The effective permission depends on the tool setting, the requested operation, and the actual working directory.

What auto approves in this release

KoboldCpp's integrated agent is a terminal harness that can read and edit files, run commands, and use a model through an OpenAI-compatible endpoint. The model can run in KoboldCpp or behind another compatible endpoint; the built-in tools still run where the agent runs. A local harness does not automatically confine those tools to an isolated machine.

The 1.123 release notes describe three global modes. on is the default and asks for approval; off approves calls without asking; auto automatically approves file work inside workdir, but requires confirmation for shell calls and outside writes or edits. Treat this as application-level approval, not an operating-system sandbox.

For a hypothetical SRE exercise, copy a sanitized incident bundle into a dedicated folder. Let the agent read the copied logs and write a proposed runbook beside them. Keeping that routine work within one directory can spare you repeated approval prompts without granting unattended shell execution.

koboldcpp --model mymodel.gguf --agent --cli

# At the agent prompt, after selecting the copied workspace:
/workdir /absolute/path/to/incident-fixture
/confirm auto
/confirm shell on
/confirm
/tools

The launch command comes from the agent guide; replace the model and directory with your own reviewed files. The last commands inspect the settings rather than asking the model to reassure you about them. Do not point this exercise at a production checkout or a directory containing credentials.

The community guide still describes an older model-review-based meaning for auto and the previous launcher tab. For these changes, use the pinned release notes and version 1.123 implementation, not a floating guide page that has not caught up.

A tool override changes the answer

The pinned implementation says per-tool confirmation settings take precedence over the global mode. If shell has an off override, selecting global auto does not restore a shell prompt. Set the shell override to on, or remove it with /confirm shell default when you want the tool to inherit the global setting.

That distinction matters because an approval prompt is a decision you make, not a rule that the action cannot ever cross. Approving a shell command gives that command the capabilities of the process running it. A command launched while the agent is in a copied workspace may still access other paths the operating-system account can reach.

If unattended shell execution is required, do not rely on workdir-based prompts as the containment boundary. Use a separately restricted account, container, or sandbox whose actual access has been tested. The OpenShell guide develops that different layer of control without treating a harness setting as proof of isolation.

Fixture action	Effective setting	Expected approval behavior to check
Write a harmless report inside the copied workdir.	write: auto	Automatic approval for an in-directory path.
Write a harmless file outside that directory.	write: auto	A confirmation prompt before the write.
Run a harmless shell command.	shell: auto or on	A confirmation prompt.
Inspect a shell tool configured with an off override.	shell: off	The tool is configured to approve without a prompt, even if the global mode is auto.

This is a proposed acceptance matrix, not a report that these model-driven calls were executed here. Keep the demonstration files disposable, cancel unexpected operations, and verify the actual filesystem after each allowed call. A model saying it wrote a file is not the same as the file existing at the intended path.

The matrix deliberately does not claim that every outside read is forced through a manual prompt. The pinned code has separate automatic-review paths for other tools. If reading outside the directory is unacceptable, enforce that restriction below the agent rather than extrapolating from the write rule.

A saved session brings back settings as well as conversation

The release adds /save, /load, and launch-time --agentload. The pinned code saves the working directory, global confirmation mode, per-tool overrides, and automation limits alongside the messages. It deliberately excludes the endpoint, API key, and model identifier, although messages themselves may contain sensitive material.

After loading a session, inspect /workdir, /confirm, and /tools before continuing. A remembered request can refer to a file that has since changed, and a restored tool override can be more permissive than the setting you expected. Saving the conversation does not freeze the destination's state.

Restored KoboldCpp settings tell you which tool calls the session will permit, but they cannot settle an earlier call whose response was lost. Keep the authorized action and the last established destination state beside that unfinished call, so the next executor can reconcile it rather than start the write again.

For the runbook exercise, that means checking whether the report already exists and reviewing its contents before asking the restored agent to create it again. Record which copied input revision it used. If the earlier task attempted an external action and lost its response, inspect that destination before retrying; session restoration cannot establish what a remote service accepted.

The release's /maxsteps and /autocompact controls bound automated turns and trigger context reduction, respectively. Neither establishes whether the requested work was correct. Once the directory and tool settings are known, give the agent a specific artifact to produce and check that artifact independently. That is how fewer prompts can make the workflow easier without making its result harder to trust.

Sources and scope

This article follows the October 13 release, the community agent guide, and the pinned source implementation. The discovery lead was the LocalLLaMA release discussion. The incident bundle and acceptance matrix are illustrative. Source inspection was performed; no local model, agent session, or production change was executed for this article.