RFC: one Discord or Slack thread per isolated Kubernetes worker Pod

[vixenclawsastraagent]

Proposal

Add an opt-in Kubernetes session runtime in which each Discord or Slack thread gets its own isolated worker Pod. The core requirement is that the ACP/CLI process for one thread cannot enumerate, read, write, or delete another thread's local worktree or other session-owned mutable state, even if it knows that state's path.

The desired operator experience is configuration-first. An operator should be able to select a Kubernetes session runtime, or a named cluster-owned runtime profile, without writing a custom dispatcher. The exact configuration schema is open for discussion; the important contract is one logical OAB session to at most one active worker Pod.

This boundary applies to execution and mutable session state. It still permits administrator-managed read-only inputs, including centrally managed skills, and explicitly configured shared services or caches.

Requirement boundary

This RFC concerns OS/runtime-enforced filesystem isolation between ACP/CLI execution sessions, not ingress-level isolation of Discord or Slack events. OAB may receive a bot mention, inspect it, and route it by thread. Preventing the raw event from entering the OAB event-handling process is out of scope.

When thread A maps to session A and thread B maps to session B, session A's ACP/CLI process must be unable to enumerate, read, write, or delete session B's local checkout or worktree, uncommitted files, mutable Git metadata, HOME, credentials, ACP/CLI state, scratch space, mutable caches, or other session-owned mutable state. The same requirement applies in reverse, even if either session knows the other session's absolute paths.

This boundary must exist before the first prompt reaches ACP/CLI and must be enforced by the OS/runtime. Branch naming, Git worktree conventions, skills, prompt instructions, or admission filtering inside OAB are not substitutes for the boundary.

"Branch isolation" in this RFC means isolation of each session's local checkout or worktree, uncommitted changes, and mutable Git state. It does not require hiding committed history or remote branches that the session's repository credentials are already authorized to fetch. Administrator-managed skills and other common inputs may remain shared when exposed read-only.

Current problem and required boundary

The target topology below is illustrative. The broker and controller may be separate or combined; the required property is the OS/runtime-enforced absence of a path between session-private writable states.

CURRENT (insufficient): logical sessions share one filesystem boundary

 Discord thread A                          Discord thread B
         |                                         |
         v                                         v
+--------------------------------------------------------------------+
| One long-lived OAB Pod                                             |
| Shared mount namespace, writable HOME, repository/PVC and Git data |
|                                                                    |
|  +------------------------+        +------------------------+       |
|  | ACP/CLI session A      |        | ACP/CLI session B      |       |
|  | worktree / branch A    |        | worktree / branch B    |       |
|  +------------------------+        +------------------------+       |
|                                                                    |
| Same mount namespace; no per-session filesystem access boundary.   |
| A can enumerate/read/write/delete B's state, and vice versa.       |
+--------------------------------------------------------------------+

REQUIRED: the runtime boundary exists before ACP/CLI receives prompt 1

 Discord / Slack event
          |
          v
+--------------------------------------------------------------------+
| OAB event handling / session routing                               |
| - receives events and maps thread ID -> logical OAB session        |
| - establishes the runtime boundary before ACP/CLI starts           |
+-------------------------------+------------------------------------+
                                |
                  +-------------+-------------+
                  |                           |
       thread A -> session A      thread B -> session B
                  |                           |
                  v                           v
     +--------------------------+  +--------------------------+
     | Worker Pod A             |  | Worker Pod B             |
     | ACP/CLI session A        |  | ACP/CLI session B        |
     | private writable state:  |  | private writable state:  |
     | - checkout/worktree A    |  | - checkout/worktree B    |
     | - HOME/Git/ACP state A   |  | - HOME/Git/ACP state B   |
     | OS/runtime-isolated FS   |  | OS/runtime-isolated FS   |
     +--------------------------+  +--------------------------+
                  ^                           ^
                  | read-only / authorized    |
                  +-------------+-------------+
                                |
                 +-------------------------------------+
                 | Allowed shared platform resources   |
                 | - skills/policies: read-only        |
                 | - services/caches: controlled API   |
                 |   and namespaced where mutable      |
                 +-------------------------------------+

 --X--> means denied by the OS/runtime, not discouraged by a prompt:
 Worker A --X--> Worker B's private writable state
 Worker B --X--> Worker A's private writable state

 Shared resources must never reveal or mutate another session's private
 writable state.

Community discussion

Canonical Discord discussion in #contributing

Initial announcement in #general (superseded as the discussion venue)

The RFC was initially shared in #general based on earlier project guidance, then reposted in #contributing after reviewing the current contribution-discussion convention. Any decisions or scope changes from the canonical discussion will be summarized in this issue so GitHub remains the source of truth.

Organizational use case

A large group in my organization is replacing the foundational agent-execution infrastructure of an internal system inspired by Stripe's Minions. We are evaluating OAB as the chat-facing broker while preserving the existing operational boundary: one isolated, disposable runtime per work session.

This is not a request to copy Stripe's implementation. It explains why separate ACP processes, branches, or working directories inside one shared Pod are not a sufficient boundary for this migration.

Why worktrees alone are insufficient

Each Git-backed session should receive a Pod-local writable checkout or worktree and its own working branch. This is a required layer of repository isolation, but it cannot by itself provide the requested runtime boundary in current OAB. For a first message, the dispatcher creates or obtains the session before forwarding the prompt; unless the user selects an existing workspace with a [[ws:...]] directive, SessionPool starts and initializes the ACP child in the agent-wide working directory and calls session/new (pool.rs). A branch/worktree skill runs only after that process has started and after the first prompt reaches the agent, so even perfect compliance cannot retroactively isolate startup.

Git documents linked worktrees as sharing everything except certain per-worktree files such as HEAD and index; common refs, repository configuration, objects, and $GIT_COMMON_DIR remain shared. A worktree therefore provides workflow separation, not an access-control boundary.

There is therefore a pre-worktree window in which a session can load steering or configuration from a shared checkout and writable HOME. Even after separate worktrees are created, processes in the same Pod can still observe or alter shared PVC contents, Git common metadata, filesystem-backed credentials, CLI configuration, hooks, plugins, and caches. They also remain inside the same resource and network boundary. This does not mean that every broker environment variable is inherited: OAB uses env_clear() and restores only baseline plus configured or selected inherited variables. The required boundary must be enforced by the runtime before the ACP process is created and before it begins handling the first human message; it cannot depend on an agent following a skill or instruction.

Isolation and intentional sharing model

The worker Pod is the per-thread execution and mutable-state boundary, not a requirement to duplicate every platform resource. The intended invariant is: shared platform inputs and services are acceptable; shared mutable session state is not.

• Session-exclusive mutable state: Each session owns its writable checkout or worktree, working branch, index and other mutable Git metadata, HOME, ACP/CLI state, configuration overlays, scratch space, session storage, credentials, and mutable caches. Other session Pods must not be able to read or modify that state.
• Centrally managed read-only inputs: Every eligible worker Pod may consume the same organization-managed skills, policies, templates, and baseline configuration from a centrally governed repository. A cluster-owned runtime profile selects an observable, preferably version-pinned revision and delivers it through an image layer, read-only initialization copy, or read-only mount. Workers cannot modify the canonical source; generated skill state and session-specific overrides remain session-local.
• Explicit shared resources: To control storage, startup, and compute cost, the profile may expose shared resources such as a source mirror, dependency or model cache, artifact store, model gateway, or another network service. Access is opt-in, least-privilege, and namespaced where mutable. A shared facility must not expose or accept another session's writable worktree, branch state, HOME, credentials, ACP/conversation state, session storage, or behavior-affecting mutable cache entries.

Worker Pods may share cluster nodes and deliberately multi-tenant services while retaining distinct Pods, cgroups, network namespaces, resource limits, and workload identities. Multiple session identities may receive the same scoped permission to a shared resource without becoming one shared identity.

Current behavior

I reviewed current main at 53061d6. My understanding is:

• A logical ACP session is keyed by <platform>:<thread_id>.
• For the normal local backend, SessionPool creates one AcpConnection and local CLI subprocess per thread.
• A first-message [[ws:...]] directive can choose a session working directory, but all of an agent's sessions still run inside the same long-lived OAB Pod. They share the Pod's mounted HOME/PVC, resource cgroup, network namespace, and workload identity boundary.
• SessionPool already persists thread-to-ACP-session mappings, attempts session/load when supported, and has idle TTL, cancel, and reset lifecycle paths. These manage local ACP processes and IDs; they do not persist or reconcile a Kubernetes worker mapping.
• The Helm chart deliberately creates one Deployment replica per agent and hardcodes replicas: 1.
• oabctl has a Kubernetes runtime schema, but both create and apply reject it as not implemented. Draft PR #1181 proposes an agent-level Deployment with one replica, rather than a dynamic worker Pod per session.
• The ECS/oabctl shape is likewise one Fargate service/task per agent, with multiple ACP sessions inside that task.
• Among the built-in/documented paths, AgentCore is the existing precedent for a remote, isolated session runtime: the broker still sees an ACP subprocess, while each session is backed by an independent microVM.

Therefore, I do not see a supported configuration today that maps each chat thread to a separate Kubernetes Pod. In particular, message_processing_mode = "per-thread" controls dispatch/batching rather than runtime isolation. Please correct any part of this reading that is wrong.

Required isolation and lifecycle contract

For this use case:

• one Discord or Slack thread maps to one logical OABSession;
• an OABSession owns at most one active Kubernetes worker Pod;
• before an ACP process is created or initialized, the runtime provisions its session-exclusive writable HOME, checkout or worktree, working branch and mutable Git metadata, ACP/CLI state, and session storage and, on Kubernetes, its exclusive worker Pod and session-writable PVC;
• no two sessions share a worker Pod, session-owned writable state, resource cgroup, network namespace, or workload identity/worker ServiceAccount; identical administrator-owned read-only inputs are allowed;
• no ACP/CLI process belonging to one session can enumerate, read, write, or delete another session's local worktree or session-owned mutable state, whether by scanning the filesystem or using a known absolute path; this is enforced by the OS/runtime rather than agent instructions, and each ACP process starts with its own session checkout or worktree as cwd;
• centrally managed skills, policies, templates, and baseline configuration may be supplied to every eligible Pod as administrator-controlled read-only inputs with an observable version;
• explicitly configured shared resources are allowed for efficiency only through controlled interfaces whose authorization and namespacing prevent cross-session state leakage or influence;
• isolation is enforced by the runtime and does not depend on an agent following branch, worktree, skill, or prompt instructions;
• worker Pods do not receive Kubernetes API credentials (automountServiceAccountToken: false); only a trusted controller receives narrowly scoped create/delete/watch permissions;
• a failed worker Pod may be replaced, but the logical session identity and thread mapping survive;
• idle sessions stop after a configurable TTL;
• cancel stops the in-flight ACP turn, while an explicit close terminates the worker and applies a configurable storage-retention policy.

Minimum acceptance test

1. Start sessions A and B from two different chat threads and confirm that the runtime assigns different worker Pod identities.
2. In A, create uniquely named, uncommitted sentinel files in the local worktree and HOME. Record their absolute paths and content hashes.
3. In A, create a local-only Git ref or branch that is not pushed to the remote.
4. From B's actual ACP/CLI execution environment, attempt to:
   • discover the sentinel files by scanning every writable mount;
   • run stat and cat against A's recorded absolute paths;
   • overwrite or delete those paths; and
   • discover or modify A's local-only Git ref.
5. B must receive ENOENT or EACCES, must not discover the sentinel contents or local-only ref, and must not change A's original content hashes.
6. Repeat the test with A and B reversed.
7. If centrally managed skills are shared, both sessions may read the same version, but a write attempt from either worker must fail with EROFS or EACCES.

Passing because the agent was instructed not to inspect another session is not acceptable. Isolation must hold for direct shell-level access attempts.

Desired configuration experience

The user-facing configuration could be as small as the following illustrative shape:

[session_runtime]
type = "kubernetes"
profile = "isolated-worker"

The referenced profile would be owned by the cluster administrator and define the worker image/template, resource requests and limits, per-session storage, network policy, worker ServiceAccount policy, idle TTL, and optional runtimeClassName. It would classify resources as session-exclusive mutable state, administrator-owned versioned read-only inputs, or explicitly allowed shared resources with a declared access policy. Keeping those security-sensitive choices in a named cluster-side profile prevents an untrusted chat session from selecting its own identity, resource policy, or cross-session sharing boundary.

I am not attached to this schema. If an ACP bridge configured under [agent] is a better fit for OAB's thin-broker model, that would also meet the configuration-first goal.

Suggested incremental design

The lowest-risk first step appears to mirror the AgentCore bridge pattern:

Discord / Slack
      -> OAB broker
      -> per-thread kubernetes-acp stdio bridge
      -> trusted session controller
      -> one ACP worker Pod

From OAB's perspective, kubernetes-acp remains an ordinary ACP subprocess. The bridge calls a controller API using the OAB session key. The controller owns Pod/PVC reconciliation and narrow Kubernetes RBAC; the worker only speaks ACP through a relay and has no Kubernetes credentials.

This could start out of tree to validate cold-start latency, streaming, replacement, cleanup, and persistence semantics without committing OAB to a new core abstraction. If the contract proves generally useful, it could later become a first-class SessionRuntime abstraction with local-process, AgentCore, and Kubernetes implementations.

One caveat is that the current pool does not expose every lifecycle distinction to a bridge: idle eviction and hard reset can both eventually look like bridge process termination. A proof of concept can begin out of tree, but reliable close-versus-suspend semantics may require a small explicit lifecycle hook in core or the first-class runtime abstraction.

My preference would be to keep OABService agent/broker-level, as proposed in #1181, and introduce a separate session-level resource/controller only if durable in-cluster reconciliation is needed. An OABSession CRD could then persist the logical session key, generation, worker/PVC references, phase, and last-active time without changing the single-replica bot connection model.

Proposed persistence semantics

A minimal persistence contract could be:

1. The thread-to-logical-session mapping and runtime generation survive broker and controller restarts.
2. Reconciliation never leaves more than one active worker Pod for one logical session.
3. A replacement Pod reuses the session's retained PVC when storage retention is enabled.
4. ACP conversation restoration remains capability-dependent: use session/load when the agent supports it, and report a visible context reset when it does not.
5. Idle TTL removes compute first. Session metadata and storage may have a separate retention TTL.
6. Explicit close removes compute immediately and deletes or retains storage according to policy.
7. An in-flight turn is not assumed durable across worker failure; replacement restores the last durable ACP/workspace state and reports the interrupted turn clearly.

Questions for maintainers

1. Is session-level Kubernetes isolation within OAB's intended scope?
2. Would you prefer an out-of-tree ACP bridge/controller first, or a first-class runtime backend in openab-core?
3. Should the proposed OABService Kubernetes backend remain agent-level, with a separate OABSession resource/controller for dynamic session Pods?
4. Does the persistence contract above match how OAB wants session identity and session/load recovery to work?
5. Would a runtime profile that distinguishes session-exclusive mutable state, centrally managed read-only inputs such as skills, and explicitly allowed shared resources fit OAB's configuration model?
6. Would optional runtimeClassName support for Kata Containers or gVisor be acceptable as defense in depth for untrusted workers?

Related work

1. chaodu-agent (2026a) Session pool leaks memory: orphaned kiro-cli processes and no eviction [GitHub issue 309]. openabdev/openab, GitHub. Available at: Session pool leaks memory: orphaned kiro-cli processes and no eviction #309 (Accessed: 30 July 2026). This completed issue improved local-process lifecycle; its industry comparison also identifies container-per-session as the stronger long-term boundary.
2. chaodu-agent (2026b) docs: add docs/firecracker.md — Kata Containers + Firecracker microVM isolation [GitHub issue 736]. openabdev/openab, GitHub. Available at: docs: add docs/firecracker.md — Kata Containers + Firecracker microVM isolation #736 (Accessed: 30 July 2026). This open issue concerns complementary runtime hardening at the Pod boundary.
3. chaodu-agent (2026c) feat: agentcore-acp adapter + ADR for AgentCore Runtime backend [GitHub pull request 1069]. openabdev/openab, GitHub. Available at: feat: agentcore-acp adapter + ADR for AgentCore Runtime backend #1069 (Accessed: 30 July 2026). This merged pull request is the closest architectural precedent.
4. chaodu-agent (2026d) docs(adr): oabctl Kubernetes backend [GitHub pull request 1181]. openabdev/openab, GitHub. Available at: docs(adr): oabctl Kubernetes backend #1181 (Accessed: 30 July 2026). This open draft addresses agent-level deployment rather than session-level workers.
5. qijie850 (2026) feat: per-thread isolated working directories [GitHub issue 38]. openabdev/openab, GitHub. Available at: feat: per-thread isolated working directories #38 (Accessed: 30 July 2026). This open issue separates working-directory paths, not Pods, PVCs, cgroups, networks, or identities.

[github-actions]

Thanks for the report! A maintainer will triage this shortly and apply the appropriate label. Once a type label is added, the issue will be re-validated automatically.

[howie]

Mob review — 2 independent LLM reviewers (Claude / Codex)

These are suggestions; the call on what to apply is yours. This is an RFC rather than a diff, so
both voices reviewed the design against 53061d6 — the commit you pinned, which was still
upstream/main's tip when this ran. Round 1 was independent (neither voice saw the other's
findings). Where a finding is marked verified, I reproduced it against the code myself rather
than taking a reviewer's word for it.

First, the part that needs no defending: your current-behavior analysis is accurate. I opened
every file:line you cited and checked all ten claims — session key shape, per-thread
AcpConnection + subprocess, the agent-wide working-dir fallback, the [[ws:...]] path,
env_clear(), the hardcoded replicas: 1, both oabctl rejection sites, the AgentCore microVM
precedent, the pool's persistence and TTL/cancel/reset paths, and message_processing_mode being
dispatch-only. Not one is wrong or overstated. Maintainers do not need to re-verify that section.

The findings below are about the proposed contract, not your reading of the current code.

---

Blocking: a zero-core-change bridge cannot satisfy your own creation invariant (verified)

Your suggested design says "The bridge calls a controller API using the OAB session key." The
bridge never receives the OAB session key — or any other per-session identity. Under the default
configuration, every per-thread bridge process is spawned with byte-identical inputs:

Site	What it shows
crates/openab-core/src/acp/pool.rs:352-358	AcpConnection::spawn is passed &self.config.command, &self.config.args, &effective_workdir, &self.config.env, &self.config.inherit_env — four of the five are global agent config
crates/openab-core/src/acp/connection.rs:328-334	the spawn() signature carries no session or thread identity at all
crates/openab-core/src/acp/connection.rs:78-85	expand_env resolves ${VAR} from the broker's own environment (std::env::var), so [agent].env cannot carry a per-session value either
crates/openab-core/src/acp/connection.rs:565-568	session_new sends only {"cwd": cwd, "mcpServers": []} — no thread id, no idempotency key
crates/openab-core/src/acp/pool.rs:342-348	with no [[ws:...]] and no stored workdir, effective_workdir falls back to the global config.working_dir, so even cwd is not discriminating

So a bridge cannot tell which logical session it is serving, which means it cannot key a controller
request by session, which means "an OABSession owns at most one active Kubernetes worker Pod"
is not enforceable out of tree. Codex framed this as a missing idempotency key on session/new;
verifying it showed the gap is wider — the entire spawn surface is session-agnostic.

The concrete failure Codex describes also holds: if the controller creates a Pod but the
session/new response is lost, OAB has not yet persisted the returned ID — pool.rs:476-482 writes
state.persisted only after creation succeeds — so a retry or broker restart has nothing to
deduplicate against and can create a second Pod. That violates persistence semantics item 2
directly.

This does not sink the proposal. It does mean the smallest viable version is not zero-core:
core has to pass a stable, broker-scoped session identity (or idempotency key) at creation time.
Deriving it from the first prompt is too late, for exactly the pre-worktree-window reason your RFC
already argues so well.

---

Additional gaps worth specifying before a PoC

1. Orphan Pod reclamation cannot be delegated to the bridge (verified)

The pool's last-resort recovery for a hung session is a SIGKILL to the child's process group:
best-effort session/cancel with a 5s timeout, then kill_pgid_after_grace(pgid)
(crates/openab-core/src/acp/pool.rs:698-723, the kill at :722).

In a bridge topology that pgid belongs to the kubernetes-acp process inside the broker Pod.
Killing it reaps the bridge; the worker Pod and its PVC survive. And because SIGKILL cannot be
caught, the bridge has no opportunity to clean up on its way out — so orphan reclamation is not
merely awkward to delegate to the bridge, it is impossible to. It has to be controller-side
reconciliation with its own TTL, from day one.

Worth calling out because this is issue #309 — which you cite as related work — recurring one level
up: orphaned Pods and PVCs instead of orphaned processes, at considerably higher cost. Persistence
item 2 covers duplicate prevention but says nothing about reclaiming a worker whose broker-side
bridge was SIGKILLed.

2. Five termination paths collapse into one signal, so item 6 is unimplementable as written (verified)

Your caveat says idle eviction and hard reset "can both eventually look like bridge process
termination". That understates it — there are five paths, and they want four different controller
responses:

Path	session/cancel sent?	Core's own bookkeeping
explicit reset (pool.rs:616-654)	yes	purges persisted / suspended / session_workdirs
idle eviction (pool.rs:749-762)	no — just dropped	retains (persisted.insert + suspended.insert)
hung eviction (pool.rs:698-723)	yes, then killpg	apply_hung_eviction
capacity eviction (pool.rs:447-459)	no	retains
broker shutdown (pool.rs:794)	no	retains mappings, clears active

All five converge on Drop → kill_process_group() (connection.rs:828). A bridge can distinguish
"died silently" from "got a cancel first", but it cannot distinguish reset from hung — and those
have opposite storage implications: a reset means the user wants a clean slate (delete session
storage), a hung eviction is an infrastructure fault (storage must be retained for the
replacement). So "explicit close removes compute immediately and deletes or retains storage
according to policy" cannot be implemented by inference from EOF or SIGTERM.

The good news is that this is a small ask, not a redesign: core already knows the difference —
reset purges persisted where idle eviction inserts into it. What's missing is only an explicit
reason passed downward. Which is why I'd promote your "may require a small explicit lifecycle hook
in core" from a later-if-useful item to a PoC prerequisite; see the answer to Q2 below.

3. The authority for session mapping is undefined, and the key lacks agent scope

pool.rs:174-180 roots persistence at $HOME/.openab/thread_map.json + session_meta.json — a
single broker-local file holding every thread's mapping (atomically written via tmp+rename at
:221-227, so that part is fine). It is durable today only because of the chart's PVC +
replicas: 1 + strategy: Recreate.

Your OABSession CRD would be a second, independent source of the same mapping. The RFC doesn't say
which wins when they disagree — e.g. after a broker is restored from an older PVC snapshot. Items 1
and 2 both presuppose a single source of truth.

Relatedly, session_key is <platform>:<thread_id> with no agent or deployment identity
(dispatch.rs:302-312), while Helm renders one Deployment per configured agent
(charts/openab/templates/deployment.yaml:1). Two bots can legitimately participate in the same
platform thread with separate ACP sessions, so a shared controller needs something closer to
(OABService UID, agent, platform, thread).

4. "The worker speaks ACP through a relay" needs explicit transport guarantees

OAB depends on an ordered, full-duplex stream, not a request/response API:

• one reader loop multiplexes notifications, request responses, and agent-initiated
  session/request_permission calls that it auto-answers (connection.rs:220);
• turn completion is request-ID correlated — adapter.rs:915-916 skips any notification whose id
  doesn't match the in-flight request;
• cancellation deliberately bypasses the connection mutex and writes to the same stdin
  concurrently with a streaming turn (pool.rs:587-608).

A buffered proxy or a request/response controller API can make streaming appear to work while
breaking mid-turn permission traffic, hard-timeout cancellation, ordering, and EOF detection. Worth
stating the relay's ordering, half-close, reconnect, stale-generation, and cancellation contract
explicitly.

5. "Never more than one active worker" needs generation fencing and a definition of "active"

Today's creation safety is an in-process per-key mutex (pool.rs:267-271) plus a
replaced-while-creating check (pool.rs:430-438). Neither has a distributed equivalent. Kubernetes
deletion and failure detection are asynchronous, so an old Pod may still be able to serve relay
traffic after its replacement starts. The controller needs fencing at the relay or lease boundary,
and the RFC should say whether terminating / unreachable / disconnected Pods count as active.

6. [[ws:...]] has no migration path — and the existing bridge precedent already drops cwd (verified)

resolve_workspace canonicalizes the path, so it must already exist, and requires it to sit
inside the canonical bot HOME subtree (directives.rs:130-143). With a session-exclusive freshly
provisioned HOME, existing aliases resolve to "Workspace path does not exist" — and on a new
session dispatch.rs:719-729 responds by calling reset_session() and aborting, so the thread's
first message fails outright rather than degrading.

The sharper point: the bridge precedent you propose to mirror already discards the supplied
cwd. crates/openab-core/src/acp/agentcore.rs:594 hardcodes "cwd": "/home/agent" in its
session/new — and that is the only occurrence of cwd in the whole file. So this isn't a
hypothetical risk of the bridge pattern; it's the observed behavior of the existing one. The RFC
should say whether aliases become logical repository seeds, how the controller provisions a private
copy, and what worker-local path reaches ACP.

---

Evidence in your favour that the RFC under-sells

Three things strengthen your case that the RFC either uses defensively or doesn't use at all.

env_clear() is your isolation model, one layer down. connection.rs:362-409 does exactly
deny-by-default-plus-explicit-allowlist: clear everything, restore a minimal baseline, then apply
explicitly configured [agent].env and explicitly enumerated inherit_env. That is structurally
the same three-way split your "isolation and intentional sharing model" proposes, applied to
environment variables. The RFC currently cites it defensively — to concede that not every broker
variable is inherited. It is much stronger used as precedent: the sharing model you're asking for is
one OAB already implements at a smaller scope. This is the best available answer to your own Q5.

Shared HOME is a design premise, not just a residual risk. Because resolve_workspace confines
every workspace to the bot HOME subtree (directives.rs:139-143), every [[ws:...]] target that
works today is inside the same HOME by construction. The shared credentials / CLI config / hooks /
caches exposure you describe isn't speculative; it's a precondition of the feature working.

Storage retention already has a precedent. charts/openab/templates/pvc.yaml renders one
ReadWriteOnce PVC per agent (the range is over .Values.agents) carrying
helm.sh/resource-policy: keep. That both confirms your reading of the current boundary and gives
you an existing convention to cite for retain-by-default.

And one finding that is yours to claim: the chart has no automountServiceAccountToken field
anywhere — only serviceAccountName (deployment.yaml:32-34). By Kubernetes default that means
today's agent Pods do receive a ServiceAccount token. Your
automountServiceAccountToken: false requirement is therefore not just future worker hardening; it
is a gap in the current broker deployment that is worth fixing independently of this RFC.

The one operational friction the RFC doesn't cost out: since per-agent PVCs are ReadWriteOnce,
per-session PVCs multiply RWO provisioning latency by the number of concurrent sessions. Worth
naming explicitly in the PoC's measurement plan alongside cold start.

---

Your questions

Q1 — Is session-level Kubernetes isolation within OAB's intended scope? Not mine to answer;
that is a maintainer roadmap call and I'm not speaking for the maintainers here. What I can say from
the code is that the shape has been accepted once already: AgentCore is a merged remote,
per-session-isolated runtime where the broker still sees an ordinary ACP subprocess
(docs/agentcore.md:189-198). So this is a scope question, not a feasibility or architectural-fit
question.

Q2 — Out-of-tree ACP bridge first, or a first-class runtime backend in openab-core? Bridge
first is the right sequencing, but the "zero core change, validate later" framing doesn't survive
contact with the pool. Three things cannot be validated out of tree, in principle:

• session identity, because the bridge is never told which session it is (blocking finding above);
• close-vs-hung storage retention, because those two are protocol-indistinguishable (gap 2);
• orphan reclamation, because the enforcement mechanism is SIGKILL to a process group and has no
  reach into the cluster (gap 1).

So the recommendation I'd put to maintainers isn't either/or: bridge out of tree for cold start,
streaming, and replacement — plus a minimal core seam from the start (a session identity at
creation and an explicit lifecycle reason on teardown), with orphan reclamation designed as
controller-side reconciliation rather than anything bridge-lifecycle-derived. Both core additions
are small and largely expose information core already holds; neither requires committing to a
SessionRuntime abstraction yet. Without them the PoC would be validating cleanup and retention
semantics that are wrong from the first day — and those are the parts most worth learning about,
since cold-start latency is the easy thing to measure in any of the three runtimes.

Q3 — Should OABService stay agent-level, with a separate OABSession resource for session
Pods? The agent-level/session-level split matches the code's own seams, so no objection from this
side — but see gap 3: if OABSession becomes durable, the RFC needs to name it or the broker's
thread_map.json as authoritative, and the session key needs agent scope before a shared controller
can key on it.

Q4 — Does the persistence contract match how OAB wants session identity and session/load
recovery to work? Item 4 (session/load when supported, visible reset when not) matches the pool
exactly, including the subtlety that a transient load failure preserves the session ID and returns
an error rather than silently continuing against a context-free session (pool.rs:365-401). Items 1
and 2 need the authority question settled (gap 3) and generation fencing (gap 5). Item 6 is not
implementable as written until the lifecycle reason exists (gap 2). Item 7's "reports the interrupted
turn clearly" has a natural home — the pool already sets a reset banner whenever it continues after
an unexpected session loss (pool.rs:413-419).

Q5 — Would a profile distinguishing session-exclusive mutable state, centrally managed read-only
inputs, and explicitly allowed shared resources fit OAB's configuration model? Yes, and
env_clear() is the argument for it — see the section above. The classification you propose is the
one OAB already applies to environment variables; extending it to filesystem, network, and identity
is a widening of an existing pattern rather than a new concept.

Q6 — Would optional runtimeClassName support for Kata or gVisor be acceptable? Acceptability
is a maintainer call, not mine. Technically it's orthogonal to everything above: it's a field on the
worker Pod template that the controller owns, so it neither helps nor hinders the identity,
lifecycle, and relay contracts that actually gate this design. It also overlaps issue #736, which
may be the better place for it.

---

How this review was produced, and where to discount it

Two voices, Round 1 independent, against a detached worktree pinned at 53061d6 (the commit the RFC
cites, and upstream/main's tip at the time). No round 2 — with one external voice lost there was
no cross-debate to run, so nothing here was arrived at by consensus-after-seeing-the-other's-answer.

Reviewer reliability, stated honestly:

• Codex produced the blocking finding and two of the gaps above (relay transport guarantees,
  generation fencing) that the Claude voice missed entirely. Some of its line numbers drift —
  agentcore.rs:589 is actually :594, and adapter.rs:862 is actually :915-916, a 53-line miss
  — so I've corrected them above rather than relaying them. Every substantive claim held up when I
  opened the files.
• Gemini (agy) is absent. It exited 0 while producing no output — headless mode auto-denied a
  file-read permission it could not prompt for. So this is a two-voice review, not three; where this
  comment says a finding was reached independently by both, that means Claude and Codex.
• Findings marked (verified) were reproduced against the code by me. Three of the gaps
  (lifecycle ambiguity, mapping authority, [[ws:...]]) were reached independently by both voices
  from different starting points, which is why I've kept them despite the missing third opinion.

Nothing was modified; this is a review-only pass on someone else's proposal. Scope and roadmap
questions (Q1, Q6) are explicitly left to the maintainers — I've given the technical input for them
rather than an answer.