Design the boundary
Choose one owner for the local terminal and permission loop. Keep the repository boundary visible and inspect any MCP servers that receive project context.
Keep access and responsibilities clear
GoCux CLI does not require or package another agent runtime. Interoperability should be an explicit adapter choice, not an invisible dependency.
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.