[robzolkos]

Your agent can read and change files in the folder you start it in, and that's all. It can't run anything: not your linter, not your tests, not git. So "fix this and make sure the tests pass" isn't something it can do. It edits the code and you run the tests.

This adds a dangerous mode you can switch on for your own agent:

basecamp connect setup -P agent --dangerous

With it on, the agent can run any command on your computer, as you. It can run the linter and tests, fix what fails, and commit. Turn it off with --dangerous=false.

Why it's called dangerous

The agent reads the whole thread it's working in, including other people's comments and attachments. With a shell, text anywhere in that thread could steer it into running something on your machine. Everything you can reach, it can reach: your files, SSH keys, your Basecamp login, cloud tokens, the network. So it's off by default, and switching it on is deliberate:

• You have to type yes. Setup explains what it means and asks you at the terminal. With no terminal (a script, or an AI running the command) it refuses, so an agent can never switch this on for itself.
• Only for an agent you alone can give work to. If others can give it work (--trust project or --allow), setup refuses and explains why. It gives the one command that makes it possible (--trust operator --dangerous). Letting people in while it's on is refused the same way, and so is changing who the operator is.
• It's hard to miss. Setup's summary, connect status, connect doctor and the connector's first log line all say it's on.

Why not for shared agents yet

If anyone in a project could give your agent work, anyone in that project could get your computer to run something, as you. Keeping it to you alone means the only person making those requests is you. It will stay off for shared agents until the agent's work can run in a box that holds only the project, with nothing of yours in it to reach.

Making sure it only ever runs your requests

• The connector reads trust once, when it starts. A connector started while others could give it work never uses dangerous mode, whatever the file says later.
• If requests from other people are still waiting from when they could give the agent work, the connector starts with dangerous mode off and says so. Those requests run as usual, never with a shell. Once they're done, a restart turns it on.
• Turning it off applies from the very next decision: the connector reads the setting fresh before every launch and follow-up. A worker already running in dangerous mode finishes what it's doing and is handed nothing more, not even new messages in its thread mid-turn. Once off, it stays off for that run: turning it back on takes a restart. Setup says so, and says how to stop it now if you want to. The off switch works with Basecamp unreachable, and with BASECAMP_TOKEN set.
• --dangerous=false on its own is the off switch, and it's saved without asking Basecamp anything, so it works offline or with a credential Basecamp no longer takes.
• Dangerous mode only applies while connect.json names the operator the connector started with, so turning it back on can never hand a previous operator a shell before a restart.
• If the connector started with dangerous mode off for that run, connect status says so, rather than claiming it's on.
• Turning it on while a connector is running asks you to restart it.
• A connect.json edited by hand to be both dangerous and shared is refused when it's read, by setup, status and the running connector alike.

How it works

• Claude Code workers get every built-in tool, Bash included, and --permission-mode bypassPermissions instead of acceptEdits.
• Codex workers run without a sandbox, with the network on. The driver checks the session Codex reports is the unsandboxed one it asked for, as it already does for the sandboxed one.
• Everything else is unchanged: your own Claude and Codex settings are still ignored, only the Basecamp tools are connected, and the worker's environment is still an allow-list.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot review overview

🟡 Changes recommended

Status can incorrectly report dangerous mode as active for safe or shadow connectors.

Review effort: Balanced
Findings: 1

Open (1)

• Shadow status incorrectly reports dangerous mode as active · New

[cubic-dev-ai]

All reported issues were addressed across 23 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[Copilot]

Copilot review overview

🟡 Changes recommended

Dangerous mode can reactivate without restart, bypass driver validation, and be reported inaccurately after lifecycle transitions.

Review effort: Balanced
Findings: 1 · 2

Open (3)

• Permanently revoke dangerous mode after off-to-on changes · New
• Preserve dangerous state across connection-state transitions · New
• Shadow status incorrectly reports dangerous mode as active

Previously missed (2)

In code that hasn't changed since last review

Reject dangerous mode with unsupported ACP driver override

internal/​commands/​connect_run.go:402

This enables dangerous policy without checking the effective driverName. Although File.Validate requires the stored driver to be spawn, basecamp connect --driver acp overrides it after the file is loaded; ACP has no ModeAnything mapping, so startup succeeds but every worker launch is unusable and work enters the start-failure hold. Refuse the ACP override when dangerous mode is effective before constructing the dispatcher.

Emit dangerous-mode notice before any other startup logs

internal/​commands/​connect_run.go:455

This is not always the connector's first log line as promised in the PR description: --hold logs at line 297, and an existing hold logs at line 302, both before this switch. Emit the dangerous-mode notice immediately after dangerousAllowedThisRun is decided so every startup path leads with it.

[cubic-dev-ai]

All reported issues were addressed across 6 files (changes from recent commits).

<sub>Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.

Re-trigger cubic</sub>

[Copilot]

Copilot review overview

🔵 Needs a closer look

Revocation can be missed across an off→on toggle, while status and machine-readable setup output also have correctness issues.

Review effort: Balanced
Findings: None

Resolved since last review (3)

• Permanently revoke dangerous mode after off-to-on changes
• Preserve dangerous state across connection-state transitions
• Shadow status incorrectly reports dangerous mode as active

Previously missed (2)

In code that hasn't changed since last review

Confirmation prose corrupts JSON output

internal/​commands/​connect.go:479

The confirmation prose is written to stdout before the normal app.OK response. With --json (or auto format on a pipe), a successful enable therefore emits several plain-text paragraphs followed by JSON, so consumers cannot parse the command's output. Send the interactive warning to stderr, as refusedChange already does, and reserve stdout for the selected output format.

Dangerous setting shortcut bypasses structured output

internal/​commands/​connect_dangerous.go:171

This shortcut bypasses the output writer entirely, so connect setup --dangerous=false --json (and auto output when piped) returns plain English rather than the repository's JSON success envelope; the already-off branch has the same problem. Keep direct prose only for styled output and use app.OK for machine-readable formats.