UpdateConfig that adds filesystem paths on a live sandbox is reported LOADED but is not enforced #5041

User Story

I use OpenShell v0.1.5 as the sandbox runtime of a self-hosted agent platform I am building (Fort): one gateway as a systemd service on Ubuntu 24.04, Docker driver, a supervisor middleware and gateway interceptors on Unix sockets. I hit this while testing that setup on two VMs.

Problem Statement

On a running sandbox, an UpdateConfig that sends the same policy plus one extra filesystem.read_only path (for example /etc) is accepted, the new revision becomes POLICY_STATUS_LOADED and active_version advances, but the workload still gets EACCES on the new path, also in processes started after the update. Removing a read_write path or changing process is rejected as expected ("cannot be removed/changed on a live sandbox"), so additions are the only filesystem change that is accepted without taking effect.

Impact / Why This Matters

GetSandboxPolicyStatus reports a filesystem policy that is not the one being enforced. A control plane that trusts the LOADED status believes a sandbox can read a path it cannot, and has no way to tell from the API. Today we treat every filesystem or Landlock change as "recreate the sandbox" and never trust the revision status for filesystem changes.

Acceptance Criteria

• An UpdateConfig that adds filesystem paths on a live sandbox is either rejected like a removal, or applied so the workload can use the path.
• GetSandboxPolicyStatus never reports LOADED for a revision whose filesystem part is not in effect.

Reproduction Steps

1. Create a sandbox whose policy has no /etc in filesystem.read_only and wait for Ready.
2. UpdateConfig with the same policy plus /etc in filesystem.read_only.
3. Wait until GetSandboxPolicyStatus shows the new revision POLICY_STATUS_LOADED.
4. ExecSandbox cat /etc/hostname → Permission denied (same in a newly started process).

Environment

• OpenShell: v0.1.5 (bdb956f), gateway release tarball, run as a systemd service (non-root openshell user)
• OS: Ubuntu 24.04 (arm64 on a Lima VM, kernel 6.8; x86_64 on a GCP VM, kernel 7.0.0-1014-gcp), Docker 29.9.2
• Deployment: single gateway, Docker compute driver, supervisor middleware on HTTPS loopback, two gateway interceptors on Unix sockets (extension auth on)

Logs

cat: /etc/hostname: Permission denied