distinct_agent/isolation/__init__.py

"""OS-level process restriction for child processes the agent spawns.

Scope, stated before anything else, because this is the area of the project
most likely to be over-read:

* **Windows is implemented and tested.** :mod:`distinct_agent.isolation.windows`
  creates a real kernel Job Object, applies process-count, memory, CPU-time and
  UI limits, and assigns the child *before it runs a single instruction*.
  ``tests/test_agent_isolation.py`` proves each limit actually bites by
  launching real processes and watching them fail.
* **Linux is design only and untested.** :mod:`distinct_agent.isolation.linux`
  contains no working implementation — only the intended namespace/seccomp/
  cgroup design, marked as such. There is no Linux host in this development
  environment, so nothing there has ever been executed, and it must not be
  described as working.

**What the Windows layer is and is not.** A Job Object is a resource-control
and containment boundary: it stops a runaway or forking child, caps what it can
consume, and guarantees no orphans survive the parent. It is *not* a full
security sandbox. The child still runs with the operator's token and can read
the files that token can read. Restricted tokens and AppContainer would narrow
that further and are not implemented; see PLAN.md §12.
"""

from __future__ import annotations

import sys

from .base import (
    IsolationUnavailable,
    ProcessRestriction,
    RestrictionReport,
    describe_support,
    spawn_restricted,
)
from .request import RequestSandbox, SandboxReport, describe_request_isolation

WINDOWS = sys.platform == "win32"

__all__ = [
    "WINDOWS",
    "IsolationUnavailable",
    "ProcessRestriction",
    "RequestSandbox",
    "RestrictionReport",
    "SandboxReport",
    "describe_request_isolation",
    "describe_support",
    "spawn_restricted",
]