hermes - 💡(How to fix) Fix Daytona terminal backend: all sandboxes named "hermes-default" → DaytonaConflictError on concurrent use

Summary

The Daytona terminal backend names every sandbox hermes-default, so two sandboxed agents running concurrently collide with DaytonaConflictError: Sandbox with name hermes-default already exists. This makes concurrent multi-agent / Kanban work impossible on the Daytona backend.

Environment

• Hermes v0.13.0 (v2026.5.7); the relevant daytona.py naming logic is byte-identical in v0.14.0 (v2026.5.16), so this is present on the latest release.
• terminal.backend: daytona

Root cause

tools/environments/daytona.py builds the sandbox name from task_id:

sandbox_name = f"hermes-{task_id}"

But task_id is deliberately collapsed to "default" by _resolve_container_task_id in tools/terminal_tool.py (the "collapse subagent task_ids to a shared container" behavior). So every Daytona sandbox is named hermes-default. Daytona requires globally-unique sandbox names, so a second concurrent create fails.

The Docker backend does not have this problem — tools/environments/docker.py uses a unique suffix: f"hermes-{uuid.uuid4().hex[:8]}". Daytona is the odd one out.

Reproduce

Run two Kanban workers (or two chat sessions) concurrently with terminal.backend: daytona. The second to create its sandbox fails:

DaytonaConflictError: Sandbox with name hermes-default already exists

Suggested fix

Mirror the Docker backend — give each Daytona sandbox a unique name:

sandbox_name = f"hermes-{task_id}-{uuid.uuid4().hex[:8]}"

Keep the existing labels = {"hermes_task_id": task_id} so the logical task id stays discoverable. Per the official Daytona SDK docs the name parameter is optional and otherwise auto-generated unique, so this also aligns with intended Daytona usage.

Impact

Without this, the Daytona backend cannot be used for any concurrent multi-agent workload — e.g. the Kanban dispatcher running multiple workers at once.