Docker deployment can hit EMFILE under normal multi-tool use due to low default nofile limit

## Summary Under normal Agent Zero Docker usage with browser sessions, shell sessions, subagents, and logging, the main UI process can exhaust file descriptors and the app degrades into repeated `OSError: [Errno 24] Too many open files` failures. This appears to be caused, or at least made much easier to hit, by the container's default soft `nofile` limit being only `1024`. ## Environment - Host: Linux - Deployment: Docker Compose - Container image: `agent0ai/agent-zero:latest` - Web UI exposed on port 50080 - Long-running container with browser/tool usage across multiple chats/projects ## What I observed Inside the running container: - Main UI process: `/opt/venv-a0/bin/python /a0/run_ui.py --dockerized=true --port=80 --host=0.0.0.0` - Process open FDs at failure time: about `1020` - Container `Max open files` soft limit: `1024` - Host limit was much higher, so this was container-local Relevant check: ```text cat /proc/1/limits ... Max open files 1024 524288 files ``` The main UI process was right at the ceiling: ```text ps -p <run_ui_pid> -o pid,ppid,comm,args= /opt/venv-a0/bin/python /a0/run_ui.py --dockerized=true --port=80 --host=0.0.0.0 ls /proc/<run_ui_pid>/fd | wc -l 1020 ``` ## Symptoms Once it reaches that state, the app starts failing in multiple places: - opening log files - opening promptinclude files - creating sockets / event loops - processing API requests reliably - restart attempts from inside the app become unreliable because the same saturated process is handling them Examples from logs: ```text OSError: [Errno 24] Too many open files: '/a0/logs/log_20260428_181416.html' ``` ```text OSError: [Errno 24] Too many open files: '/a0/plugins/_promptinclude/prompts/agent.system.promptinclude.md' ``` ```text OSError: [Errno 24] Too many open files File "/opt/pyenv/versions/3.12.4/lib/python3.12/socket.py", line 610, in socketpair ``` There were also follow-on asyncio cleanup warnings after the FD exhaustion. ## Behavior impact This makes the UI look like it is "choking" or partially restarting while still failing requests. A host-side `docker compose down && docker compose up -d` recovers it, but the issue can recur. ## Temporary workaround Raising `nofile` in Docker Compose appears to be the right immediate mitigation: ```yaml services: agent-zero: ulimits: nofile: soft: 65535 hard: 65535 ``` ## Why I think this is worth fixing upstream A0 in Docker commonly uses: - Playwright / browser processes - multiple shell sessions - subagents - prompt includes - logs - long-lived chats So `1024` is too easy to exhaust in real use. Even if there is also an underlying FD leak or session cleanup gap, the default container limit seems too low for the product's normal workload profile. ## Requests 1. Ship a higher default `nofile` for Docker deployments, or document it prominently. 2. Review whether browser sessions / tool sessions / logs are leaking descriptors over time. 3. Consider graceful degradation or cleanup before the main UI process reaches hard failure. If useful, I can provide the exact stack traces I saw, but the core repro/evidence above should already be enough to investigate.