Build an n8n Code-Change Workflow With Human Approval and Test Verification

The workflow at a glance

Use n8n to let an AI agent propose a repository change, but put the write operation behind human approval. After an approved write, run tests against the exact resulting commit and report the outcome. Keep merging or deployment as a separate decision.

The key distinction is tool approval versus output approval. In n8n, a human-review step can pause an AI Agent before a selected tool executes. The reviewer sees the proposed tool and its parameters; approval executes that call, while denial cancels it and informs the agent. This behavior is documented in n8n's human-in-the-loop guide.

OneMux provides access to AI models through one OpenAI-compatible API. It is a possible model-access route for this design, not a verified n8n integration. Check the OneMux API documentation and your n8n node's configuration against the endpoint and parameters you intend to use.

What you need before building

• An n8n instance with an AI Agent, a suitable chat model connection, and access to a human-review channel such as Slack or n8n Chat.
• A repository integration or custom service that can read a specified revision and apply a patch to a non-production branch. Give its write credential only the access needed for that repository and branch.
• A test runner isolated from production credentials and systems. It must accept an exact commit identifier and return a status and a link or reference to its results.
• A OneMux account and API access if you choose OneMux for model calls. Consult the quickstart for current connection details and the model catalogue when selecting an available model.
• A repository with a known test command, a protected default branch, and a person authorized to review proposed changes.

This is an implementation pattern, not an importable workflow. Repository tools, runner integration, model choice, and exact n8n fields depend on your environment. In particular, the supplied documentation does not establish that a specific OneMux model supports the tool-calling behavior required by an n8n AI Agent. Verify that support before relying on this design.

Design the workflow around an exact revision

A practical sequence is:

1. Receive a request. Capture the repository, issue description, target working branch, base commit, and allowed test command from trusted workflow configuration.
2. Read and propose. Let the agent inspect the relevant files at the base commit and prepare a patch. Read access should not be able to modify the repository.
3. Review the write. Route the patch application tool through n8n human review. The reviewer approves or denies the proposed tool call.
4. Apply and identify. If approved, the write service checks that the branch still points to the approved base commit, applies the approved patch, and returns the new commit ID. If the base changed, fail closed and request a new proposal and approval.
5. Verify. Run the configured tests against that exact new commit in an isolated runner. Record the command, commit, status, and result reference.
6. Report. Send the reviewer and requester the commit and test result. A failed, canceled, or missing test result is not a pass.

These are recommended controls, not features guaranteed by n8n's human-review step. In particular, your repository service must enforce the base-commit check and ensure that the approved patch is the patch it applies.

Configure the model connection

In n8n, choose a chat model configuration that supports a configurable OpenAI-compatible endpoint and the tool-calling behavior your AI Agent needs. Use the endpoint, authentication method, and model identifier specified in the current OneMux documentation. Store credentials in n8n's credential system rather than in prompts or workflow messages.

Before connecting repository access, make a small test request and check that the response arrives in the format expected by the n8n node. Then test a harmless tool call. OpenAI-compatible does not mean every endpoint, parameter, or tool-call format is interchangeable: compatibility here is conditional on both sides supporting the required requests and responses. This configuration has not been tested for this article.

If your available model connection cannot support the agent's tool calls, do not bypass approval by giving the model direct write credentials. Use a compatible configuration or build a separate, explicitly reviewed handoff to the write service.

Add a human gate to the repository write

In the AI Agent node, open the Tools connector and find Human review in the Tools Panel. Select an approval channel and configure its credentials. Connect the repository-writing tool to the review step's tool connector. Keep read-only tools separate where appropriate, and place any other tools that can change external state behind their own review or equivalent control.

The n8n documentation says the reviewer can receive the tool name and AI-supplied parameters. For example, configure the review message with:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Use a write tool whose reviewable inputs include the repository, branch, base commit, and full patch or an immutable patch reference with a digest. If the patch is too large for the channel, provide a secure, accessible review location and verify that the write service applies the same content. A vague instruction such as “fix the tests” is not enough to approve a specific repository change.

The documented $tool.parameters values include fields configured with $fromAI() expressions; do not assume the message exposes every fixed credential, hidden configuration value, or downstream effect. Keep fixed settings constrained and give reviewers a separate way to inspect them. Avoid placing secrets in tool parameters, because parameters may appear in approval messages.

Add a system instruction that names the gated tool and tells the agent what to do on denial. For example:

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

This instruction helps the agent handle review; it is not a security boundary. Enforce permissions and branch restrictions outside the prompt.

Verify the approved change

Trigger the test runner only after the write service returns a commit ID. Configure the runner to check out that ID, not the latest branch head, and execute an allowlisted command defined by your team. For a repository whose maintainers have chosen it, an example command might be:

npm test

That command is illustrative; use the project's actual test instructions. Treat repository code, dependency installation scripts, and test output as untrusted. Run them with restricted network and filesystem access, without production secrets, and with time and resource limits. A passing test suite shows only that the selected checks passed in that environment; it does not prove the change is safe or correct.

Return a concise result containing the approved base, new commit, test command, pass/fail status, and a link to logs. If tests fail, the agent may propose a revised patch, but a further write needs its own approval. Do not automatically merge because a reviewer approved the earlier tool call.

Troubleshooting and operating limits

The approval request lacks useful context

Check which inputs are AI-supplied and visible in $tool.parameters. Put the patch identity, branch, and base revision in the reviewable tool input or provide a secure immutable review artifact. If the reviewer cannot identify the exact write, deny it.

The agent cannot call the tool

First test a harmless tool independently of repository permissions. Check the n8n node, OneMux endpoint, selected model, and required tool-call parameters against their current documentation. The supplied sources do not verify a particular model-node combination.

The branch moved or tests did not finish

Reject a stale write rather than applying a patch to a different base. For a timeout, runner error, or missing log, report verification as incomplete. Re-run against the same commit when appropriate; request a new approval if the proposed write changes.

Conclusion

The useful boundary is narrow: a person approves a specific repository write, and an isolated runner verifies the resulting commit. n8n supplies the documented tool-level pause and approval flow; your repository service, runner, permissions, and review process supply the remaining safeguards. Use OneMux as the model-access layer only after confirming that the chosen endpoint and parameters work with your n8n configuration.

Sources

• n8n: Human-in-the-loop for tools — tool approval behavior, setup, review channels, and review-message variables.
• OneMux documentation — consult for current API connection details.