Design the boundary
Keep editor assistance anchored to the selected repository. Review file access, terminal execution and MCP permissions separately, and use the project checks to judge the output.
Keep access and responsibilities clear
GoCux customer CLI has its own local agent loop. An editor article does not turn that loop into a bundled editor extension.
Test a small path first
- Choose one known input and write down the expected output.
- Check authentication, cancellation and an unavailable-service response before widening the task.
- Keep an auditable distinction between data retrieval, generated suggestions and external changes.
A practical starting point
Use the local agent for a bounded development task. These steps describe the GoCux workflow and its permission boundaries.
- Connect the customer CLI through the supported device flow and choose a specific local repository or working directory. Preserve unrelated files and existing work.
- Give the local agent a concrete goal and review its tool permissions. The CLI owns its local terminal, tool and MCP loop; model routing sits behind GOCUX Gateway.
- Read the resulting diff and run the checks appropriate to the changed surface. Keep local verification separate from any later publishing or deployment action.
What to verify
A useful completion record identifies the changed files and the checks that passed. Optional cloud automation is separate from ordinary CLI and web conversation.
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.