Coding agents in a local AI loop
Coding agents are easy to demo in chat and harder to run safely against real repositories. Windshift's runner gives them a local, sandboxed path into the normal work loop.
Coding agents are easy to demo in chat and harder to run as part of a real engineering workflow. The awkward questions start once the task leaves the prompt box: which repository can it touch, where does it run, who pays for the model, where do secrets go, and how does the team review what happened?
For self-hosted teams, those questions matter more than the demo. A useful agent needs enough access to do real work, but not open-ended access to every repo, credential, and network path. It also needs to report back in the place where planning and review already happen.
That is the premise behind Windshift's coding-agent runner. A Windshift item already has the title, description, comments, linked pages, status, owner, and repository context. The agent can start there instead of asking someone to rebuild the whole task in a chat prompt.
Assignment is the trigger
The workflow is intentionally plain. Assign a bug investigation, docs update, cleanup task, or small implementation item to the agent. The agent reads the item, checks linked resources, and reports back on the item if it needs a human decision.
That matters for team flow. A coding run is not a separate chat thread that someone has to paste back into the tracker. The request, transcript, branch, and result stay attached to the work item.
The runner keeps work contained
The Windshift server queues and tracks runs. The runner host does the execution.
Each job gets a fresh agent container and a per-run checkout. The agent does not run as a long-lived process with old state hanging around between tasks. The sandbox limits what the container can touch, gives it only the mounted repository workspace, and keeps broad credentials out of the container.
Model choice stays replaceable
Background work changes the model decision. You do not need every run to use the most expensive model available. Many tasks are bounded enough for cheaper coding models:
Because the agent binding chooses the LLM connection, different agents can use different models and budgets. Routine maintenance can run on a cheaper model. Larger changes can use a stronger one. The model provider remains a replaceable endpoint inside the same Windshift workflow.
Local knowledge comes from skills
Teams often need agents to follow local habits: which tests to run, how migrations are written, how large a PR should be, what docs need updating, and which files own a feature.
Windshift agent skills handle that as managed Markdown knowledge packs. Admins attach skills to a binding, and the agent can read them during a run. The repo does not need a giant instruction file, and the agent does not need to guess team rules from nearby code.
The result is reviewable
Every run has a status and an event log. The item detail view can show the agent transcript, including command output, tool results, failures, and the final summary.
If the run produced commits, Windshift opens a draft PR and links it back to the item. In the example run, Windshift opened a live Codeberg pull request, realigned/windshift-core#14, from `agent-runs/run-45` into `main`.
Local with guardrails
Running coding agents locally is a control choice. You choose where Windshift runs, where the runner runs, which model endpoint is used, which repository the agent can touch, and which skills it can read.
There is still infrastructure to operate. Runner hosts need Docker, and they should be treated as dedicated execution machines. The design keeps the agent's access narrow, but generated code still needs normal review, tests, and branch rules.