You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an OpenShell operator, I want profile-backed providers to be the single way that sandboxes receive model-provider access, so that provider credentials, endpoint policy, and sandbox attachment lifecycle are configured through one consistent workflow.
Problem Statement
OpenShell currently exposes https://inference.local inside every sandbox and manages its upstream through a separate workspace-level inference route. It also carries a second sandbox-system route intended for supervisor-internal platform inference. Providers v2 now supports authoritative provider profiles, per-sandbox provider attachment, provider-owned network policy, and endpoint-bound credential injection. Keeping these managed inference routes duplicates that provider model with gateway-managed route state, separate openshell inference configuration, model pinning, and route-bundle delivery.
Remove both inference.local and sandbox-system, including the managed inference configuration and bundle-delivery surface, and make profile-backed providers the supported path for model-provider access. No production code currently calls the sandbox-system in-process API; it exists only in its implementation and tests.
Impact / Why This Matters
Today users must understand and maintain two overlapping abstractions: provider records/attachments for direct provider access and a workspace-global inference route for inference.local. The latter applies one provider and model across all sandboxes in a workspace, while provider attachments are scoped to individual sandboxes. This creates ambiguous ownership, prevents provider attachment from being the complete access contract, constrains clients to the proxy's supported API patterns, and expands the CLI, API, policy, routing, documentation, and test surface.
Users can already attach a provider and call its native endpoint, but current documentation presents that path alongside inference.local and still auto-allows the virtual host. Maintaining both paths adds operational and security-review cost without a distinct sandbox use case now that provider profiles own endpoints, L7 policy, and credential binding.
Proposed Design
Make profile-backed providers the only user-facing mechanism for granting a sandbox access to an inference provider:
Users create or select a provider profile and provider instance.
Users attach that provider when creating a sandbox or with openshell sandbox provider attach.
Code in the sandbox calls the provider's native endpoint and uses the provider-defined environment/config contract. OpenShell continues to enforce the profile-derived network policy and inject credentials only at authorized endpoints.
Detaching the provider revokes its policy and credential access for that sandbox.
Stop exposing, resolving, documenting, or implicitly allowing inference.local for sandbox workloads. Remove sandbox-system and its unused in-process supervisor API as well. Remove the managed inference CLI commands, gRPC configuration and bundle-delivery API, persisted route state, and supervisor route refresh/partitioning behavior. Existing installations should receive clear upgrade guidance that maps inference.local configurations to provider attachment and native endpoint usage rather than silently preserving the old feature. If a concrete platform-level inference consumer is introduced later, it should get an explicit provider-backed design based on that consumer's identity, policy, credential, and lifecycle requirements rather than retaining a speculative shared route.
Acceptance Criteria
New and upgraded sandboxes do not resolve, trust, implicitly allow, or route requests to inference.local.
The gateway no longer persists or delivers inference.local or sandbox-system routes, and removes the managed inference route/bundle API surface.
The openshell inference set|get|update|delete command surface is removed.
Attaching an inference-capable provider grants only that sandbox the profile-defined native endpoints, policy, and endpoint-bound credentials; detaching it revokes that access according to the provider lifecycle contract.
Built-in inference provider profiles contain the endpoint, protocol, credential, and configuration metadata required for supported clients to call their native APIs without inference.local.
OpenAI-compatible, Anthropic-compatible, and other supported inference-provider paths have end-to-end coverage through provider attachment and native endpoints.
Existing inference.local route state has deterministic upgrade behavior and the release notes provide a concrete migration from inference-route configuration to provider attachment.
README, published documentation, tutorials, architecture docs, CLI help, and public/internal agent skills no longer present inference.local as a sandbox feature.
Protobuf comments, generated SDK surfaces, policy defaults, certificates/DNS handling, router configuration, logging, and tests no longer carry sandbox-facing inference.local assumptions.
The sandbox-system route, supervisor route cache, and in-process system_inference() API are removed, with tests confirming no platform functionality depends on them.
The replacement preserves OpenShell's credential non-disclosure, endpoint binding, policy enforcement, hot-refresh, and OCSF logging guarantees.
Alternatives Considered
Keep inference.local alongside providers v2. This preserves compatibility but leaves users and maintainers with two overlapping ways to grant model access and retains workspace-global behavior that conflicts with per-sandbox provider attachment.
Automatically create an inference.local route when an inference-capable provider is attached. This makes attachment more convenient but preserves the virtual endpoint, model-routing abstraction, and duplicate routing/credential path that this proposal removes.
Deprecate inference.local indefinitely. A short, documented migration window may be appropriate, but maintaining both mechanisms as supported features would defer rather than eliminate the ambiguity and maintenance burden.
Retain sandbox-system for future platform functions. The route was introduced for a possible embedded agent harness such as policy analysis, but there is no production caller today. Keeping it would preserve much of the managed inference configuration, bundle, route-cache, and router machinery for a speculative consumer whose actual authorization and provider-lifecycle requirements are not yet defined.
docs/providers/profiles.mdx documents per-sandbox attach/detach, just-in-time provider policy composition, and endpoint-bound credential injection. It still lists inference mounting from attached providers as a roadmap item and points users to the separate inference.local model.
docs/sandboxes/inference-routing.mdx documents inference.local as one workspace-level provider/model route shared by every sandbox, configured with openshell inference.
proto/inference.proto and crates/openshell-server/src/inference.rs default empty route names to inference.local while also carrying the distinct sandbox-system route.
The current tree contains inference.local references across 54 files, including CLI/server/router/policy code, protobuf and generated SDKs, e2e tests, README, architecture docs, published docs, and public/internal skills.
User Story
As an OpenShell operator, I want profile-backed providers to be the single way that sandboxes receive model-provider access, so that provider credentials, endpoint policy, and sandbox attachment lifecycle are configured through one consistent workflow.
Problem Statement
OpenShell currently exposes
https://inference.localinside every sandbox and manages its upstream through a separate workspace-level inference route. It also carries a secondsandbox-systemroute intended for supervisor-internal platform inference. Providers v2 now supports authoritative provider profiles, per-sandbox provider attachment, provider-owned network policy, and endpoint-bound credential injection. Keeping these managed inference routes duplicates that provider model with gateway-managed route state, separateopenshell inferenceconfiguration, model pinning, and route-bundle delivery.Remove both
inference.localandsandbox-system, including the managed inference configuration and bundle-delivery surface, and make profile-backed providers the supported path for model-provider access. No production code currently calls thesandbox-systemin-process API; it exists only in its implementation and tests.Impact / Why This Matters
Today users must understand and maintain two overlapping abstractions: provider records/attachments for direct provider access and a workspace-global inference route for
inference.local. The latter applies one provider and model across all sandboxes in a workspace, while provider attachments are scoped to individual sandboxes. This creates ambiguous ownership, prevents provider attachment from being the complete access contract, constrains clients to the proxy's supported API patterns, and expands the CLI, API, policy, routing, documentation, and test surface.Users can already attach a provider and call its native endpoint, but current documentation presents that path alongside
inference.localand still auto-allows the virtual host. Maintaining both paths adds operational and security-review cost without a distinct sandbox use case now that provider profiles own endpoints, L7 policy, and credential binding.Proposed Design
Make profile-backed providers the only user-facing mechanism for granting a sandbox access to an inference provider:
openshell sandbox provider attach.Stop exposing, resolving, documenting, or implicitly allowing
inference.localfor sandbox workloads. Removesandbox-systemand its unused in-process supervisor API as well. Remove the managed inference CLI commands, gRPC configuration and bundle-delivery API, persisted route state, and supervisor route refresh/partitioning behavior. Existing installations should receive clear upgrade guidance that mapsinference.localconfigurations to provider attachment and native endpoint usage rather than silently preserving the old feature. If a concrete platform-level inference consumer is introduced later, it should get an explicit provider-backed design based on that consumer's identity, policy, credential, and lifecycle requirements rather than retaining a speculative shared route.Acceptance Criteria
inference.local.inference.localorsandbox-systemroutes, and removes the managed inference route/bundle API surface.openshell inference set|get|update|deletecommand surface is removed.inference.local.inference.localroute state has deterministic upgrade behavior and the release notes provide a concrete migration from inference-route configuration to provider attachment.inference.localas a sandbox feature.inference.localassumptions.sandbox-systemroute, supervisor route cache, and in-processsystem_inference()API are removed, with tests confirming no platform functionality depends on them.Alternatives Considered
Keep
inference.localalongside providers v2. This preserves compatibility but leaves users and maintainers with two overlapping ways to grant model access and retains workspace-global behavior that conflicts with per-sandbox provider attachment.Automatically create an
inference.localroute when an inference-capable provider is attached. This makes attachment more convenient but preserves the virtual endpoint, model-routing abstraction, and duplicate routing/credential path that this proposal removes.Deprecate
inference.localindefinitely. A short, documented migration window may be appropriate, but maintaining both mechanisms as supported features would defer rather than eliminate the ambiguity and maintenance burden.Retain
sandbox-systemfor future platform functions. The route was introduced for a possible embedded agent harness such as policy analysis, but there is no production caller today. Keeping it would preserve much of the managed inference configuration, bundle, route-cache, and router machinery for a speculative consumer whose actual authorization and provider-lifecycle requirements are not yet defined.Agent Investigation
docs/providers/profiles.mdxdocuments per-sandbox attach/detach, just-in-time provider policy composition, and endpoint-bound credential injection. It still lists inference mounting from attached providers as a roadmap item and points users to the separateinference.localmodel.docs/sandboxes/inference-routing.mdxdocumentsinference.localas one workspace-level provider/model route shared by every sandbox, configured withopenshell inference.proto/inference.protoandcrates/openshell-server/src/inference.rsdefault empty route names toinference.localwhile also carrying the distinctsandbox-systemroute.sandbox-systemwas introduced by feat: add sandbox.inference.local endpoint for system-level inference #207/feat(inference): add sandbox-system inference route for platform-level inference #209 for possible platform functions such as an embedded policy-analysis harness. The currentsystem_inference()API has no production call sites; only its implementation and integration tests reference it.inference.localreferences across 54 files, including CLI/server/router/policy code, protobuf and generated SDKs, e2e tests, README, architecture docs, published docs, and public/internal skills.Checklist