fix: tolerate cross-loop shutdown + add DockerSandbox extra_hosts

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else:

[Yunnglin]

Two unrelated but small changes bundled in one PR (happy to split if preferred).

1. fix(local_manager): tolerate cross-loop shutdown of cleanup task

Symptom: At interpreter exit, processes that drive the sandbox manager via a per-worker asyncio loop print

WARNING: SandboxService: error stopping manager: Event loop is closed
ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-7' coro=<LocalSandboxManager._cleanup_loop()>>

Cause: LocalSandboxManager._cleanup_task is created on whatever asyncio loop first calls start() — in practice a per-worker thread loop. When that worker thread tears its loop down (typical finally: loop.close() pattern) before atexit-driven SandboxService.shutdown_all reaches us, manager.stop() running on a different loop tries to cancel() + await the task. The task's owner loop is gone, so:

• await self._cleanup_task raises RuntimeError: Event loop is closed
• the task remains in pending state → asyncio's Task.__del__ prints the second line on GC

Fix: detect a closed owner loop and (a) suppress the asyncio pending-task warning via _log_destroy_pending, (b) skip the cancel/await dance entirely (the cancellation can't be driven to completion anyway). Tolerate RuntimeError in the live-loop branch as belt-and-suspenders.

Reproduction (no eval framework needed):

importasyncio, threadingfromms_enclave.sandbox.manager.local_managerimportLocalSandboxManagerasyncdefsetup_only():
mgr=LocalSandboxManager()
awaitmgr.start()
returnmgrout= []
defworker():
loop=asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
out.append(loop.run_until_complete(setup_only()))
finally:
loop.close()
t=threading.Thread(target=worker); t.start(); t.join()
main_loop=asyncio.new_event_loop()
asyncio.set_event_loop(main_loop)
main_loop.run_until_complete(out[0].stop()) # raised "Event loop is closed" beforemain_loop.close()

Before this PR: prints Event loop is closed + Task was destroyed but it is pending.
After this PR: clean exit.

End-to-end verified through evalscope's SWE-bench Pro × external codex pipeline (3 samples, ~10 min) — both noise lines gone.

2. feat(docker_sandbox): expose extra_hosts on DockerSandboxConfig

Adds a Dict[str, str] field forwarded verbatim to docker-py's extra_hosts kwarg, so containers can be launched with custom /etc/hosts entries. The motivating use case is {"host.docker.internal": "host-gateway"} to reach host services from inside the container on Linux, where that alias is not auto-provided (Docker Desktop adds it automatically on macOS/Windows but not on plain dockerd Linux).

Documented on the field; no behavioural change when left as the default empty dict.

Test plan

• Repro snippet above goes from noisy → clean
• evalscope SWE-bench Pro × codex run (3 samples) — clean shutdown
• Existing ms-enclave tests pass (please run in CI)

[gemini-code-assist]

Code Review

This pull request introduces the extra_hosts configuration for Docker sandboxes, allowing custom host-to-IP mappings in /etc/hosts. It also improves the shutdown logic in local_manager.py to prevent asyncio warnings when cleaning up tasks across different event loops. Feedback suggests further refining the task cleanup by checking if the task is already done and ensuring internal warning suppression is applied if a RuntimeError occurs during the await process.

[Copilot]

Pull request overview

This PR makes two targeted improvements in ms_enclave’s sandbox runtime: (1) hardens LocalSandboxManager.stop() against interpreter-exit shutdown when the cleanup task’s owning event loop has already been closed, and (2) adds support for passing Docker extra_hosts entries via DockerSandboxConfig to improve host reachability from Linux containers.

Changes:

• Make LocalSandboxManager.stop() tolerate cleanup-task shutdown when the task’s event loop is already closed.
• Add extra_hosts: Dict[str, str] to DockerSandboxConfig.
• Forward extra_hosts into Docker container creation in DockerSandbox.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ms_enclave/sandbox/manager/local_manager.py	Adds cross-loop shutdown handling for the background cleanup task during manager stop.
ms_enclave/sandbox/model/config.py	Extends DockerSandboxConfig with an extra_hosts mapping field.
ms_enclave/sandbox/boxes/docker_sandbox.py	Passes extra_hosts through to docker-py’s container create() call.

Comments suppressed due to low confidence (1)

ms_enclave/sandbox/manager/local_manager.py:71

• stop() writes to the private Task._log_destroy_pending attribute without any guard. Because this is an internal asyncio implementation detail, it may be missing or become read-only across Python versions/implementations, which would turn shutdown into an AttributeError. Consider using hasattr/setattr inside a try/except (AttributeError, TypeError) and falling back to a best-effort cancel() + dropping the reference when it cannot be modified.

 if task_loop is None or task_loop.is_closed():
self._cleanup_task._log_destroy_pending = False
else: