Code review and refactoring
Ask NuBench to review the files in a directory, identify patterns that violate your team's conventions, and produce a refactored version. NuBench reads the actual files on your machine — not a pasted excerpt.
How it works — Dev Worker
Your local environment, governed by your security policy
The NuBench Dev Worker is a lightweight CLI that gives NuBench agents secure, bounded access to your local codebase. The agent logic runs in NuBench infrastructure. Tool calls — read a file, write a change, run a test — execute locally on your machine via an outbound-only HTTPS connection. No inbound ports. No VPN. No firewall changes.
How it works
- 01
Install the CLI
Install the nubench-worker CLI via npm or Homebrew. The worker is a lightweight Node.js process. It requires no inbound ports, no VPN, and no firewall changes. The only network requirement is outbound HTTPS to NuBench — the same connection your browser uses.
npm install -g @nubench/worker or brew install nubench/tap/worker - 02
Register your workspace
Run nubench-worker register in the directory you want to make available. The worker registers the workspace path with your NuBench session. The workspace boundary is declared at registration time and is immutable for the session — the worker cannot access files outside it.
nubench-worker register --workspace ./my-project - 03
Agent calls execute locally
When a NuBench agent makes a file operation — read, write, edit, run a test — the agent loop running in the cloud dispatches the tool call to your local worker over the outbound HTTPS connection. The worker validates the HMAC-signed call, checks it against the allow-list, executes it within the registered workspace, and returns the result.
The agent logic runs in NuBench infrastructure. Your files never leave your machine.
Security model
Every security property of the Dev Worker was designed with the assumption that the network path between your machine and NuBench infrastructure could be compromised. These are the controls that hold even in that scenario.
- Outbound HTTPS only
- The worker makes outbound connections to the NuBench gateway — it never opens a listening port. Your firewall policy does not need to change. No inbound traffic reaches your machine from NuBench infrastructure.
- HMAC-signed tool calls
- Every tool call dispatched from the NuBench agent loop to your local worker is signed with HMAC-SHA256. The worker validates the signature before executing any instruction. This prevents replay attacks and blocks injection from a compromised network path between the cloud and your machine.
- Allow-list enforcement
- The worker only executes tool calls from the NuBench-defined allow-list: file read, write, edit, limited Bash within the workspace directory, and Git operations. Any tool call outside the allow-list is rejected and logged as an unauthorized tool call event — it does not execute.
- Workspace boundary
- The workspace directory declared at registration is immutable for the session. Any write attempt outside this boundary is rejected, logged, and triggers a GRC boundary violation event. NuBench infrastructure cannot initiate writes outside your declared workspace.
- Short-lived credentials
- The worker authenticates to NuBench using a short-lived signed JWT with a 15-minute lifetime, issued by the NuBench gateway at worker registration. There are no long-lived static credentials. Compromising a token grants access for at most 15 minutes before the next renewal is required.
What your team can do with it
Local test execution
NuBench can run your test suite, read the failure output, identify the root cause, propose a fix, apply it, and re-run the tests — all in a single governed conversation with full audit trail.
Multi-file edits
Describe a change that spans multiple files. NuBench reads the relevant context across your codebase, drafts the edits, and applies them — with every write operation logged and reversible with standard Git tooling.
Classification carries into your codebase
The classification tier of the conversation in which the Dev Worker is active applies to all file operations in that session. A PHI-classified session enforces restricted model routing, PHI-eligible model selection, and PHI classification on any output written by the worker. Repository classification is assigned at connection time and cannot be downgraded after PHI or PII code has been committed to that repository.