Summary

Three issues found in the Daytona terminal backend during investigation of reported "malicious activity" sandbox kills (which we could not reproduce — see below).

1. FileSyncManager uploads 580 files sequentially (performance)

File: tools/environments/file_sync.py → _daytona_upload() in tools/environments/daytona.py

FileSyncManager.sync() calls _daytona_upload() once per file. Each call does sandbox.fs.upload_file() — one HTTP POST with a fresh TLS handshake per file. With ~580 skill/credential/cache files, sandbox init takes ~5 minutes.

The Daytona SDK already has a bulk upload API:

from daytona.common.filesystem import FileUpload
sandbox.fs.upload_files([
    FileUpload(source=local_path, destination=remote_path)
    for local_path, remote_path in files_to_sync
])

This would batch all 580 files into a single HTTP call. Same pattern applies to SSH and Modal backends.

Impact: ~5 min init → <2s init.

2. Config YAML container_memory/container_disk not bridged to env vars

File: hermes_cli/config.py (env var bridge map, ~line 2770), tools/terminal_tool.py (~line 646)

terminal_tool.py reads resource config from env vars:

"container_memory": _parse_env_var("TERMINAL_CONTAINER_MEMORY", "5120"),
"container_disk": _parse_env_var("TERMINAL_CONTAINER_DISK", "51200"),

The config.yaml→env-var bridge in config.py maps terminal.daytona_image → TERMINAL_DAYTONA_IMAGE but does not map:

• terminal.container_memory → TERMINAL_CONTAINER_MEMORY
• terminal.container_disk → TERMINAL_CONTAINER_DISK
• terminal.container_cpu → TERMINAL_CONTAINER_CPU

So setting container_memory: 2048 in config.yaml has no effect. Users must export the env vars manually.

3. Daytona disk cap warning invisible in agent mode

File: tools/environments/daytona.py lines 65-71

Default container_disk is 51200 MB (50GB). Daytona caps at 10GB. The code uses warnings.warn():

warnings.warn(
    f"Daytona: requested disk ({disk_gib}GB) exceeds platform limit (10GB). "
    f"Capping to 10GB.",
    stacklevel=2,
)

warnings.warn() is invisible when running as a gateway/agent. Should be logger.warning() instead (or both).

Context: "malicious activity" investigation

A user reported Daytona sandboxes being killed for "malicious activity" due to "python base64+exec code patterns." We investigated the codebase and confirmed the patterns exist:

• code_execution_tool.py _ship_file_to_remote() — base64.b64encode() → echo ... | base64 -d > script.py → python3 script.py
• environments/modal.py _modal_upload() — same pattern
• environments/tool_context.py upload_file() — same pattern
• skills/red-teaming/godmode/scripts/ — exec(compile(open(path).read(), ...))

However, we could not reproduce the detection after running:

1. Isolated base64+exec pattern tests
2. Godmode skill file uploads + base64 exec combined
3. Full hermes-agent 3-turn session (terminal + execute_code) on Daytona

All sandboxes survived. The detection may be volume/time-dependent, tier-specific, or triggered by LLM-generated content rather than hermes source patterns.