Using an AI Coding CLI: Context, Permissions and Diff Review

Start with a task you can verify

“Improve this repository” leaves too much undefined. A stronger task names a symptom, the expected behavior and the constraints. For example: a contact form loses the draft after a failed request; preserve the draft and show a retry option.

Write down what would prove the fix works before asking for an edit. This keeps the assistant’s work reviewable and gives you a stopping point. The same approach applies to tools such as Aman CLI without assuming any particular permission system is implemented.

Inspect the contact form and its request handler.
Explain why a failed request clears the draft.
Make the smallest fix that preserves the input.
Do not add dependencies or make network requests.
Show the diff and run relevant local checks.
Report anything you could not verify.

Give context without giving away the workspace

Start with the relevant files, project instructions and the failing behavior. Expand the scope when there is a reason. Sending unrelated files adds noise and can expose information the task never needed.

Check what your specific tool sends to its model provider. A terminal interface does not imply local inference or offline processing. Keep credentials, private exports and unrelated documents outside the accessible context.

Do not treat .gitignore as a security boundary. It affects Git tracking; it does not prevent a program with filesystem access from reading an ignored file. Repository files and tool output can also contain hostile instructions. Treat them as task data, not authority to change your security settings.

Separate permission prompts from isolation

An approval prompt asks whether an action may run. A sandbox restricts what an action can reach. One does not replace the other. GitHub Copilot CLI, for example, documents separate controls for allowing and denying tool use; other tools have different defaults.

Before approving a command, check the target files, possible network access and whether it invokes another script. Broad approval for a shell or package manager can allow much more than one visible command. Prefer permissions narrow enough for the current task.

Source: GitHub Docs: allowing and denying CLI tool use

Review the patch, not just the explanation

An assistant’s summary is a guide to the change, not evidence that the change is correct. Inspect the actual diff. Look for unrelated edits, removed validation, new dependencies, changed permissions and tests that were weakened to pass.

These Git commands show the working-tree state, summarize unstaged changes and check the unstaged patch for whitespace errors. The final command shows staged changes. Untracked files appear in status but not in ordinary diff output, so inspect those separately.

A clean whitespace check says nothing about correctness or security. Read the code and run checks that exercise the behavior you intended to change.

git status --short
git diff --stat
git diff
git diff --check
git diff --cached

Source: Git documentation: comparing working-tree and staged changes

Finish with evidence and a recovery path

For the contact-form example, check a failed request, a successful request and a second submission. Confirm that the draft survives failure and that the success state does not invite accidental duplicate sends. Test with a mock endpoint instead of sending real messages.

A branch or worktree helps separate edits, but it does not isolate a process from your machine. A “dry run” is only meaningful if that particular command documents what it skips. Neither is a substitute for understanding the action.

Before committing, distinguish your existing edits from the assistant’s changes. Keep a recoverable copy of work you care about, review what is staged, and record which checks passed. If a check could not run, leave that limitation visible instead of calling the work verified.