---
type: "post"
id: "apexe-0-10-0-adds-governed-shell-and-62d1e3"
slug: "apexe-0-10-0-adds-governed-shell-and-62d1e3"
title: "apexe 0.10.0 adds governed shell and agent setup for Claude Code, Codex, OpenCode and pi"
description: "AI Perceivable’s apexe 0.10.0 adds a shell launcher and setup commands for Claude Code, Codex, OpenCode and pi."
retrieval_nugget: "AI Perceivable’s apexe 0.10.0 adds a shell launcher and setup commands for Claude Code, Codex, OpenCode and pi. It gives teams a shared way to route command execution through apexe’s shims and policies, while the changelog is explicit that a restricted PATH is not a sandbox."
published_at: "2026-11-06"
updated_at: "2026-11-06"
record_date: "2026-11-06"
date_kind: "published_at"
topics: ["claude","claude-code","codex"]
entities: ["AI Perceivable","apexe","Claude Code","Codex","OpenCode","pi"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
what_changed: "A separate apexe 0.10.0 release adds governed shell and agent setup integrations across Claude Code, Codex, OpenCode and pi."
prior_refs: ["https://newruntime.com/posts/opencode-2-2-3-adds-a-built-in-f00886/"]
source_url: "https://github.com/aiperceivable/apexe/blob/main/CHANGELOG.md"
source_urls: ["https://github.com/aiperceivable/apexe/blob/main/CHANGELOG.md"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:apexe-0-10-0-adds-governed-shell-and-62d1e3"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/apexe-0-10-0-adds-governed-shell-and-62d1e3/","markdown":"https://newruntime.com/posts/apexe-0-10-0-adds-governed-shell-and-62d1e3.md","json":"https://newruntime.com/posts/apexe-0-10-0-adds-governed-shell-and-62d1e3.json"}
markdown_url: "https://newruntime.com/posts/apexe-0-10-0-adds-governed-shell-and-62d1e3.md"
---

# apexe 0.10.0 adds governed shell and agent setup for Claude Code, Codex, OpenCode and pi

## Retrieval answer

AI Perceivable’s apexe 0.10.0 adds a shell launcher and setup commands for Claude Code, Codex, OpenCode and pi. It gives teams a shared way to route command execution through apexe’s shims and policies, while the changelog is explicit that a restricted PATH is not a sandbox.

## Summary
AI Perceivable’s apexe 0.10.0 adds a shell launcher and setup commands for Claude Code, Codex, OpenCode and pi. It gives teams a shared way to route command execution through apexe’s shims and policies, while the changelog is explicit that a restricted PATH is not a sandbox.

## What happened
AI Perceivable’s changelog dates apexe 0.10.0 to 6 November 2026. The release adds `apexe sh`, which starts a real shell through the installed shim environment, forwards arguments verbatim and can report readiness with `--check` in text or JSON. `apexe env --enable` can install a stable `apexe-sh` entry point for hosts that select a shell by path. The changelog draws a boundary around this capability: it changes command lookup order, but is not a sandbox or a full-governance boundary.

A locked mode, `apexe sh --locked`, limits `PATH` to the shim directory plus explicitly allowed directories. The entry point can take that configuration from `APEXE_SHELL_LOCKED` and `APEXE_SHELL_ALLOW_PATH`; checks report local policy and the denylist. The release also changes environment handling: local shim and native execution inherit caller variables, including examples such as `GH_TOKEN`, `AWS_PROFILE`, `KUBECONFIG` and `SSH_AUTH_SOCK`, while dynamic-loader hooks such as `LD_PRELOAD` and `DYLD_*` are removed before a child starts. Captured MCP/A2A execution retains its existing scrubbed allowlist.

The new `apexe agent <host>` command prints setup for OpenCode, pi, Codex or Claude Code using the installed `apexe-sh` path. With `--write`, it merges configuration atomically; `--check` reports launcher and host readiness. `--mcp-only` generates an MCP-only deployment for OpenCode or Claude Code, while Codex prints TOML. The changelog says `--write` now refuses to point a host at a launcher that is not installed. For pi and OpenCode, the shell path is a hard dependency: if absent, the host will not run commands rather than falling back to the system shell.

Other changes target policy and recovery. `apexe env --enable --replace-unowned` can regenerate apexe’s entry point and activation helpers if the ownership record is missing, while remaining scoped to reserved names and not replacing an existing file on a command name. Routes without a reviewed overlay can be installed as `--scanned off|readonly|all`; scanned execution validates the caller’s arguments and executes the original argument vector without rebuilding or reordering it, and audits calls with a `scanned` tier. Local execution also adds bounded terminal approval prompts for `requires_approval` modules; non-interactive stdin is refused with a remedy. Claude Code hooks can route Bash calls through apexe, including an experimental persistent session, but the changelog limits that session to a host session ID and project directory with idle timeout and explicit stop.

## What the archive adds
Earlier coverage has tracked OpenCode reusing Claude Code logins and models in a [separate provider release](https://newruntime.com/posts/opencode-2-2-3-adds-a-built-in-f00886/). That is related context, not the same event: apexe 0.10.0 adds command-execution governance and setup across multiple hosts. This is a new fact in the broader story of coding-agent workflows sharing context and infrastructure.

## Trend signal
This supports the [shared-context infrastructure assumption](https://newruntime.com/shifts/shared-context-infrastructure/): developers can use several AI clients on one project, creating value for common project-level tooling. apexe offers a shared shell/configuration path, though the changelog does not establish how widely teams use it or whether hosts behave identically.

## Why now
The release’s setup command names four coding-agent hosts, and its shell entry point is designed for hosts that select an executable shell by path. That makes the integration problem concrete: command governance has to fit the host’s launch contract, not just an agent’s prompt. The changelog provides no market or adoption data explaining the timing.

## Why it matters
Teams increasingly need to decide which commands an agent can reach, where those commands come from and when a human must approve an operation. A common shim layer can make those controls more consistent across coding-agent clients than maintaining separate command wrappers for each host. The release’s `--check` and route diagnostics also make some readiness and coverage gaps visible before a team enables more execution paths.

The limits matter as much as the integration. A restricted PATH narrows command discovery but does not isolate filesystem access or otherwise establish a security boundary. Teams should treat apexe as one component in a layered execution policy, test host behavior, and distinguish reviewed, readonly and scanned routes. They should also verify which environment variables reach local child processes: preserving credentials supports ordinary workflows but makes the surrounding runtime controls consequential.

## Limits and uncertainty
The changelog describes implementation and configuration, not independent security testing, adoption, performance or reliability results. It explicitly says `apexe sh` and locked PATH are not a sandbox or full-governance boundary. It does not establish that every command is safe, that every host interprets setup the same way, or that generated configurations match a team’s policies without review. The persistent Claude hook is marked experimental and scoped to a host session and project directory. No pricing or usage figures are included.

## Skill to build now
Map one coding-agent workflow’s command surface before enabling it: list the CLI routes the agent needs, mark which are readonly, which need human approval and which should remain unavailable, then inspect apexe’s diagnostics against that list. If testing 0.10.0, start with a non-production project and confirm which credentials and paths reach child processes; do not treat locked PATH as isolation.

## Reader takeaway
apexe 0.10.0 makes it easier to connect several coding-agent hosts to a shared, policy-aware shell and setup flow. Its controls may help teams standardize command access, but the release itself says the shell and restricted PATH are not a sandbox. Treat it as an integration layer to test within a broader runtime security design.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Claude](https://newruntime.com/topics/claude.md): Explore the claude topic hub.
- topic hub: [Claude Code](https://newruntime.com/topics/claude-code.md): Explore the claude-code topic hub.
- topic hub: [Codex](https://newruntime.com/topics/codex.md): Explore the codex topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)