FirstbeamUnderstand permissions before running a task
A practical guide to read-only work, edits and provider approval.
Match permission to responsibility
Use read-only access when an agent needs to understand a repository without changing it. Editing permissions are appropriate for implementation work whose changes you can review. The permission selected in Firstbeam is passed through the engine’s supported runtime; the engine retains its own approval behavior.
Read an approval in context
Check the action, target paths and scope. An approval for one operation is not a blanket instruction to publish, delete data or change account access. Keep task instructions specific enough that the agent knows what result is expected.
Tool permissions are separate
MCP tools may require their own authentication and access. Microphone capture needs Windows/WebView permission before a transcription provider is called. Changing a model or a billing plan does not grant either kind of access.
Keep a reviewable result
After a task, inspect changed files, tests and the reported limits. Use version control for recoverable changes and project memory for decisions. Do not include credentials in reusable instructions or feedback attachments.
Separate inspection from implementation
Ask a read-only agent to identify the relevant files, describe the data flow and propose the smallest correction. Assign implementation only after the scope is clear. Review the resulting diff and tests before publishing a build. This keeps analysis useful without giving investigation more editing access than it needs.
Keep recovery practical
Use a clean version-control checkpoint or an appropriate isolated worktree before a broad edit. Keep local user changes identifiable and do not treat them as disposable test data. If a task stops midway, inspect what was changed and what checks completed before asking an agent to resume; elapsed time is not evidence of completion.