Use idapt Code safely
Found this helpful? Share it:
Found this helpful? Share it:
idapt Code adds no permission mode of its own. Every command it runs is bounded by the same four layers that govern any agent computer command, and the local daemon is the one that actually enforces them.
| Layer | What it controls | Where you change it |
|---|---|---|
| Workspace access | Who can use this workspace's resources and credentials | Workspace members |
| Computer policy | Which daemon capabilities are available at all | On the computer itself |
| Operating-system permissions | Which files, processes, and credentials a command can reach | The machine's user accounts |
| Port access mode | Who can open a forwarded port | The port forward, when you create it |
Pairing only proves which computer resource the daemon belongs to. It enables nothing on its own.
Coding needs Shell and File access. It does not need admin operations or desktop control. Enable them one at a time on the machine:
idapt-computer service policy enable remote-shell
idapt-computer service policy enable remote-filesChanging a capability restarts the daemon so the new policy takes effect immediately.
full-control enables shell, file access, admin operations, desktop control,
and the interactive terminal in one step. That is a much larger grant than a
coding task needs, and it is not the way to unblock one.
Each capability shows as Allowed or Blocked in the computer's Permissions list on its Dashboard. In the idapt desktop app, viewing the machine it runs on, Manage opens the native permissions window with the same toggles. Both routes act on the computer, never from the browser alone.
Shell and file access let the agent read anything that operating-system account can read. Choose accordingly:
A development account, virtual machine, container host, or cloud computer for anything unfamiliar.
Not an account that also holds production credentials, administrative sessions, or unrelated personal data.
A cloud computer is the cheapest way to keep a risky task away from your workstation, and you can discard it when the task ends.
Repository instructions, source files, generated files, test fixtures, and dependency lifecycle scripts can all carry instructions aimed at the agent. Before running an unfamiliar project:
Ask the agent to read the repository instructions and package scripts without executing them.
The skill asks before destructive commands, system-wide installation, privilege escalation, and work outside the project you named. It never widens computer policy itself.
A development server stays private until you forward its port. Pick the narrowest access mode that lets the reviewer in, avoid exposing admin panels or anything holding live credentials, and close the port when the review ends. See Ports and port forwarding.
Related articles
Start coding with idapt Code
Point a normal idapt Chat at a paired or cloud computer and have it read the project, change code, run the tests, and report what it did.
Git credentials for coding sessions
Let the agent push and open pull requests with the computer's existing Git setup, or hand it one workspace credential for a single command.
Computers
Pair your own machine or launch a cloud one, then let your AI run commands and work with files on it.
Daemon troubleshooting
What to do when a paired computer goes offline, fails an update, blocks a capability, or won't reconnect.
Credentials
Store API keys and app connections once, then let your commands, functions, and agents use them without pasting a key into a chat.
Ports and port forwarding
Forward a port on one of your computers to an authenticated public URL through a tunnel, then close it again.
Was this helpful?