fix(agents): enforce sandbox disabled on remote and cloud workplaces

[DeryFerd]

Background

Docker sandbox mode only applies to local workplaces. Remote SSH and cloud (Evonet) workplaces run tools through different execution backends, so a sandbox toggle on those agents does not mean what the UI implies.

There was a gap in how agent create/update handled sandbox_enabled:

• On create, validation only ran when sandbox_enabled was truthy, so sending 0 skipped the workplace check entirely.
• On update, the same truthy guard applied, and when the user tried to enable sandbox on a remote/cloud workplace the code deleted sandbox_enabled from the payload instead of writing 0. The old value in SQLite could stay out of sync with what the settings page shows.

Issue #35 reported the toggle feeling ineffective; the underlying issue is that policy was not applied consistently on every save path.

How it behaves now

A small helper, _apply_sandbox_workplace_policy(), looks up the target workplace and, for remote or cloud types, always sets sandbox_enabled to 0 on the data dict passed to the database layer.

Both API entry points call it:

• POST /api/agents — uses workplace_id from the create body.
• PUT /api/agents/<id> — uses workplace_id from the body when present, otherwise the agent’s existing workplace.

That means a partial update (name, prompt, channel, etc.) on a cloud agent still persists sandbox_enabled=0, even when the client omits the sandbox field. Local workplaces are unchanged: both 0 and 1 pass through as sent.

The agent detail UI already disables the sandbox toggle for remote/cloud; this change makes the stored agent record match that expectation.

Files touched

• routes/agents.py — _apply_sandbox_workplace_policy() plus calls from create/update handlers.
• unit_tests/test_agent_sandbox_workplace_validation.py — unit tests against the helper (local allowed, remote/cloud forced off, no lookup when workplace_id is missing).

Notes for reviewers

• This is separate from workplace file I/O delegation (#36).
• No migration: agents with stale values get corrected the next time they are updated through the API; new creates are correct immediately.
• Setup wizard / CLI agent flows were not modified in this PR; happy to follow up if those paths need the same helper.

Checked with

• python -m pytest unit_tests/test_agent_sandbox_workplace_validation.py -q

[anvie]

Thank you for the PR! This is a clean fix for a real bug (issue #35).

The two bugs in the old code are clear:

1. Create: if data.get('sandbox_enabled') skips the check entirely when the client sends sandbox_enabled=0 — a remote/cloud agent could be created with stale sandbox state.
2. Update: same falsy guard plus del data['sandbox_enabled'] instead of setting to 0 — the old DB value persists through partial updates.

The new _apply_sandbox_workplace_policy() helper fixes both: always called, always writes 0 for remote/cloud.

Test coverage is solid — all three workplace types, both on/off states, and the no-workplace-id edge case with assert_not_called. Clean use of unittest.mock.patch.

One non-blocking note: the dashboard api_setup() creates the super agent with a local workspace, so it's not affected. But if the setup wizard ever gains workplace selection, the same helper should be called there.

Full review report saved at artifacts/pr41-review.md.

Best,
Richard

Robin Syihab's agent.