Devin (Devin CLI and Devin Desktop)

The devin connector wires DefenseClaw into the native Devin CLI lifecycle-hook surface. Devin continues to contact its model provider directly; DefenseClaw does not proxy its model traffic.

What this connector protects

The hook contract was reviewed against Devin CLI 3000.4.25 on Windows, macOS and Linux. On Linux it is also pinned to 3000.11.3, which a live check showed delivers the SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop and SessionEnd events under these names and honors exit-code-2 blocks on UserPromptSubmit and PreToolUse (PermissionRequest and PostCompaction are not verified). Any other Devin CLI version from 3000.4.25 on, on every OS, uses the same contract as an untested newer version unless it is known broken (version policy).

Platform support

Setup

defenseclaw setup devin --mode observe
defenseclaw setup devin --mode action

defenseclaw setup devin --mode observe
defenseclaw setup devin --mode action

Use --mode action only after reviewing observed events and policy findings. The connector can join an existing hook-connector roster. After setup, restart any open Devin CLI session and reopen Devin Desktop tabs so they load the new hooks.

Native Windows

On Windows the contract is pinned to Devin CLI 3000.4.25; the extra 3000.11.3 pin is Linux only. A newer CLI, such as 3000.11.x, uses the same contract, and setup reports it as an untested newer version. A CLI older than 3000.4.25 has no contract, so setup keeps it in observe mode and refuses action mode.

Devin evaluates hook commands through its own Bash execution path on Windows. DefenseClaw therefore registers the protected defenseclaw-hook.exe as a Bash-safe direct command. This preserves the hook JSON streams and blocking exit code without a PowerShell decode boundary. DefenseClaw does not install or add Bash, WSL, Docker, a VM, Git Bash, Cygwin/MSYS, or a proxy dependency.

Configuration custody

DefenseClaw manages only the documented Devin-native hook locations. Devin CLI and Devin Desktop's Devin Local agent read the same files:

• Windows user hooks: %APPDATA%\devin\config.json, nested under hooks;
• macOS/Linux user hooks: ~/.config/devin/config.json, nested under hooks;
• project hooks: <workspace>/.devin/hooks.v1.json, where the hook map is the whole JSONC document.

Existing foreign hook groups and JSONC content are preserved. Devin also loads hooks from .claude/ settings for compatibility; DefenseClaw does not claim or modify those locations.

In a standalone enterprise deployment on Linux and macOS, each hook runs the administrator-owned hook binary with defenseclaw-hook hook --connector devin --enterprise-managed, which runs the foreign-hook guard and always fails closed: the Devin fail mode is closed whatever hook_fail_mode says, and status and the hook-contract lock report it that way. See Machine policy.

Devin Desktop in a standalone enterprise deployment

Devin Desktop starts its bundled Devin Local agent as devin acp, and Devin Local reads the same user and project hook config as the Devin CLI (Devin Local, ACP, hooks). Under the standalone enterprise profile DefenseClaw also:

• Enrolls Desktop-only users. A user with Devin Desktop but no devin CLI is enrolled at the version of the Devin CLI that Devin Desktop bundles, read from that CLI's man page without running anything. Discovery looks for Devin.app in /Applications or ~/Applications on macOS; for /usr/share/devin-desktop (the .deb package) or an unpacked .tar.gz Devin folder in /opt or the user's home on Linux; and for Devin.exe in %LOCALAPPDATA%\Programs\Devin or %ProgramFiles%\Devin on Windows. A bundled CLI version from 3000.4.25 on (Devin Desktop 3.10 bundles 3000.10.x) is enrolled as an untested newer version. One below 3000.4.25 or on the known-broken list, or a Desktop with no bundled CLI, is recorded in unprotected-agents.json instead, as is any Desktop under enterprise.enrollment.unverified_versions: refuse until Devin Desktop completes a live validation run.
• Checks plugin hooks. Devin plugins can ship hooks that run in every local session, the CLI and Devin Local, and can rewrite tool input (plugins). The foreign-hook guard scans the plugins installed in the Devin CLI data folder (~/.local/share/devin/cli/plugins, or $XDG_DATA_HOME; %LOCALAPPDATA% on Windows), including a plugin installed with --local from another folder. The cleanup reports plugin hooks and leaves them in place: the user uninstalls the plugin.
• Reports ACP registry entries. defenseclaw-gateway enterprise policy show lists the entries of the user's Devin Desktop ACP registry that start an agent DefenseClaw does not cover on the host, or that start Devin Local with --config (which replaces the user config file) or with workspace trust turned off. It reports these entries and changes nothing.
• Tags the agent host. Each managed hook sends the name of the process that started the agent, which the gateway records as agent_host in the hook audit event, so the audit can separate Devin Local from the CLI.
• Explains session blocks. One Devin Local process serves every Desktop tab, so a foreign-hook session block covers all tabs. When the block comes from Devin Desktop the message says to quit and reopen Devin Desktop.

Devin Desktop's own enterprise policies cover extensions and updates, not hooks, and Cascade's system hook files (Cascade hooks) do not apply to Devin Local. Devin Desktop on these paths has not completed a live validation run.

Cascade on older builds

Devin Desktop builds before 3.9.19 still run the Cascade agent, which reads a machine-level hooks file that standard users cannot change and blocks an action when a hook exits with code 2 (Cascade hooks). While devin is a standalone enterprise connector, DefenseClaw adds one entry to each blocking Cascade event (pre_user_prompt, pre_read_code, pre_write_code, pre_run_command, pre_mcp_tool_use). The entry prints a message that says to update Devin Desktop and use Devin Local, and exits with code 2. It runs nothing else, so the refusal needs no enrollment, runtime or gateway. Administrator entries in the file are kept.

Devin Desktop reads the pre-rename machine hooks file only when the Devin file is absent, and pre-rename apps read only the pre-rename file. So DefenseClaw writes into each of the two files that exists, and creates only the Devin file when neither exists; it never creates the Devin file beside an existing pre-rename one, which would stop Devin Desktop from running the administrator's hooks there. Builds from 3.9.19 on have no Cascade and ignore the entries.

Other Cascade hooks (cloud, user and workspace) still run, but a hook can only add a block, so none of them undoes the refusal. Also turn Cascade off in your Devin team settings. Set enterprise.machine_policy.connectors.devincascade.ownership to verify_only when your MDM owns the file (deploy the output of defenseclaw-gateway enterprise policy export --connector devincascade), or to "off" to leave Cascade running.

Lifecycle and enforcement

The devin-hooks-v1 contract registers exactly eight events:

The gateway's verdict uses Devin's top-level decision and reason. A block exits 2, and Devin shows that hook's output as it is (Tool rejected: <output>), so on a block the hook prints only the reason text. hookSpecificOutput is event-tagged; DefenseClaw emits additionalContext only for UserPromptSubmit, SessionStart, and PostToolUse. Exit 2 blocks, while every other hook error fails open. Restricted Mode disables hooks and agents entirely.

Devin documents session_id and per-turn prompt_id, but no per-tool invocation ID. Devin CLI 3000.11.3 also sends an undocumented tool_use_id, which DefenseClaw does not rely on. Cross-event tool pairing is therefore detection-only. A confirm finding remains available in audit but cannot pause and resume in the DefenseClaw TUI.

Hook capabilities

Local customization surfaces

Read/write MCP custody is limited to the canonical user and project mcp_config.json files. Higher-precedence local compatibility files may be read for effective inventory but are not rewritten. Skills and rules are discovered from the documented .devin and .agents roots, including AGENT.md, AGENTS.md, and AGENTS.local.md where applicable. Inventory also reads the pre-rename Devin Desktop rule and skill locations that the vendor still loads (see Cognition's memories and rules and skills documentation). Setup never installs anything there; defenseclaw skill quarantine and restore can move a flagged skill out of and back into those folders, as for any other skill folder. Traversal is bounded and does not follow links or reparse points.

DefenseClaw does not install Devin plugins or register hooks through them; in a standalone enterprise deployment the foreign-hook guard checks the hooks of installed plugins. The separate devin acp entry point is cataloged for the shared ACP guard, but it has not completed official-client testing and is not part of this hook contract. Cloud Devin execution, proxy transport, native OTLP, sandboxing, egress control, and managed higher-layer policy are also outside this connector's support boundary.

Upgrading an older Devin Desktop install

Upgrades migrate the previous Devin Desktop connector automatically; you do not need to edit files by hand. The details, including what DefenseClaw removes and what it leaves alone, are in Upgrade → Renamed and removed connectors.

In an OpenShell sandbox

The sandbox guide covers the sandbox commands. What the Devin CLI image already holds:

• User tier. Devin has no system hook tier, so the hooks are in ~/.config/devin/config.json inside the image, a file the agent can edit. The launcher puts the DefenseClaw hooks back from a root-owned template on every start and refuses a --config of your own. Devin blocks only on exit code 2, so the sandbox hook exits 2 on every failure, with a 30-second timeout per hook.
• Skip-permissions. Devin would start with --permission-mode dangerous; its autonomous mode needs Devin's own sandbox, which cannot run inside OpenShell. --safe drops --permission-mode dangerous and --permission-mode autonomous from the arguments you pass.
• Hook tamper detection. DefenseClaw pairs each tool call's PostToolUse with its PreToolUse by session, tool name and tool input, so a tool that ran although DefenseClaw denied it, or whose PreToolUse hook never reached DefenseClaw, raises a hook_tamper finding and the pack's hooks.on_tamper applies (see Sandbox policy). Measured on a logged-in Devin CLI 3000.11.3: PostToolUse fires only for a tool that ran, not for a call a hook denied or you refused at Devin's permission prompt.
• Workspace trust is skipped. A headless Devin run fails in an untrusted folder, and a declined trust prompt runs Devin without hooks, so the launcher always passes --respect-workspace-trust false and refuses that flag from you. The trade-off: a project's own Devin hooks (.devin/hooks.v1.json) load next to DefenseClaw's without a prompt.
• Sign-in. A Devin account login inside the sandbox (/usr/local/lib/defenseclaw/bin/devin-launch auth login --force-manual-token-flow, which runs devin auth login through the launcher; paste the token from the browser flow) is the only sign-in. The credential stays in the sandbox's ~/.local/share/devin, where the agent can read it and send it out. It was not tested live.
• Image. Devin CLI 3000.4.25 from its release archive, checked against the SHA-256 in Devin's release manifest.

Disable

If Devin is the only connector DefenseClaw guards, turn the guardrail off:

defenseclaw guardrail disable --yes

If other connectors are configured too, turn off Devin alone and keep the rest running:

defenseclaw guardrail disable --connector devin --yes

Both keep Devin's settings, so defenseclaw guardrail enable (with the same --connector) turns it back on. To drop Devin from the configured connectors instead, run defenseclaw setup remove devin --yes; add --force when it is the last connector.