feat(cua): add managed sandbox lifecycle dashboard

[zouyonghe]

Summary

• Add managed CUA sandbox registry, leases, defaults, lifecycle tools, startup reconciliation, and persistent registry saves.
• Add provider-neutral dashboard sandbox APIs and a Sandbox Management page with create/default/config/release/destroy/screenshot and non-takeover shell console controls.
• Improve CUA local image diagnostics, shell/boot logging, and document CUA image preparation.

Verification

• uv run pytest tests/unit/test_cua_registry.py tests/unit/test_cua_computer_use.py tests/unit/test_cua_sandbox_tools.py tests/unit/test_core_lifecycle.py tests/unit/test_computer.py tests/unit/test_func_tool_manager.py tests/unit/test_astr_main_agent.py tests/test_dashboard.py -q
• uv run ruff check astrbot/core/astr_main_agent.py astrbot/core/computer/booters/cua.py astrbot/core/computer/computer_client.py astrbot/core/computer/cua_registry.py astrbot/core/core_lifecycle.py astrbot/core/tools/computer_tools/__init__.py astrbot/core/tools/computer_tools/cua.py astrbot/core/tools/computer_tools/cua_sandbox.py astrbot/core/tools/computer_tools/shell.py astrbot/dashboard/routes/sandbox.py tests/unit/test_cua_registry.py tests/unit/test_cua_computer_use.py tests/unit/test_cua_sandbox_tools.py tests/unit/test_core_lifecycle.py tests/unit/test_func_tool_manager.py tests/unit/test_astr_main_agent.py tests/test_dashboard.py
• cd dashboard && pnpm typecheck
• cd dashboard && pnpm build

[sourcery-ai]

Sorry @zouyonghe, your pull request is larger than the review limit of 150000 diff characters

[gemini-code-assist]

Code Review

This pull request introduces comprehensive CUA sandbox management features, including new tools for listing, creating, switching, releasing, taking over, destroying sandboxes, taking screenshots, and copying files between them. It also adds a CuaSandboxRegistry for persistent sandbox state management and integrates a new dashboard route for sandbox administration. Review feedback points out a resource leak with unclosed file descriptors, a potential startup crash due to unhandled JSON parsing errors in the registry, and a bug related to inconsistent use of time sources for timeout calculations. Additionally, there are suggestions for improving dictionary access patterns in the dashboard routes for better robustness.

[gemini-code-assist]

The use of tempfile.mkstemp creates a low-level file handle and a file path, but the file handle (file descriptor) is not being closed. This will lead to a resource leak, which could eventually exhaust the available file descriptors for the process.

You should explicitly close the file descriptor after getting it from mkstemp.

Suggested change

	relay_file = Path(
	tempfile.mkstemp(prefix="cua-relay-", suffix=".tmp", dir=relay_root)[1]
	)
	fd, relay_path = tempfile.mkstemp(prefix="cua-relay-", suffix=".tmp", dir=relay_root)
	os.close(fd)
	relay_file = Path(relay_path)

[gemini-code-assist]

The json.load(f) call is not wrapped in a try...except block. If the sandbox_registry.json file becomes corrupted or is malformed, this will raise a json.JSONDecodeError (or OSError for other read issues), which is unhandled. Since this load() method is called during application startup, a corrupted registry file will prevent the application from starting.

It would be more robust to catch potential exceptions here, log a warning, and proceed with a default empty payload, allowing the application to start and recover gracefully.

Suggested change

	with self.storage_path.open("r", encoding="utf-8") as f:
	payload = json.load(f)
	try:
	with self.storage_path.open("r", encoding="utf-8") as f:
	payload = json.load(f)
	except (json.JSONDecodeError, OSError):
	# Consider logging a warning here about the corrupted registry file.
	self._payload = _default_registry_payload()
	return

[gemini-code-assist]

There's a potential issue here with mixing time sources. last_used_at is based on wall-clock time (time.time()), while the idle cleanup task's expiration (current_expires_at) is based on a monotonic clock (time.monotonic()).

The calculation idle_remaining = timeout - (time.time() - float(last_used_at)) uses wall-clock time. Then, this duration is added to time.monotonic() to set a new monotonic expiration time.

If the system's wall-clock time is adjusted (e.g., by NTP), this can lead to incorrect timeout calculations. idle_remaining could become very large or small, causing the sandbox to either never expire or expire too soon.

It's recommended to consistently use time.monotonic() for scheduling and duration calculations within a single process lifetime to avoid this. Since last_used_at must be persisted as wall-clock time, you could calculate the sleep duration based on wall-clock time and then use that duration with asyncio.sleep.

[gemini-code-assist]

The expression str(data["sandbox_id"]) if data.get("sandbox_id") else None is a bit fragile. If data.get("sandbox_id") is truthy, it then accesses data["sandbox_id"] using bracket notation, which could raise a KeyError under unusual circumstances (though unlikely here). A simpler and safer approach is to just use data.get("sandbox_id"), as the function you are calling (release_current_cua_sandbox) already expects str | None.

                _session_id(data),
                data.get("sandbox_id"),

[gemini-code-assist]

Similar to another comment, the expression str(data["cwd"]) if data.get("cwd") else None is unnecessarily complex and slightly fragile. Using data.get("cwd") is sufficient, cleaner, and safer as it will return None if the key is missing, which is the desired behavior.

Suggested change

	cwd=str(data["cwd"]) if data.get("cwd") else None,
	cwd=data.get("cwd"),

[sourcery-ai]

Sorry @zouyonghe, your pull request is larger than the review limit of 150000 diff characters