Add Gentle Shell as an independent Connect target #7208

Area

Multiple areas

What are you trying to accomplish?

Add Gentle Shell as an independent Connect/export/refresh destination in the CLI and Dashboard while keeping Codex and Pi as separate, independently owned installations.

What prevents this today?

OpenCodex already supports Pi and other model-client integrations, but it has no first-class Gentle Shell target. Selecting the wrong persistent home can otherwise share, link to, or overwrite another client’s model configuration. Although Pi and Gentle Shell use the same transport model, their homes and settings must remain independent.

What should OpenCodex do?

Expose gentle-shell as a distinct integration target. It should safely resolve a persistent Gentle Shell home from its launcher configuration and supported environment selectors, refuse shared/link/Pi destinations and ambiguous selectors, show it in the Dashboard with independent branding, and export and refresh only catalogs the target owns.

The implementation reuses the existing Pi protocol/serializer so the installed target behaves consistently, while retaining its own registry identity, ownership journal, refresh enrollment, CLI contract, and GUI surface.

Example usage or interface

ocx export --client gentle-shell
ocx integrations refresh

Dashboard:

Integrations → gentle-shell shows Gentle Shell independently from Pi and never activates it automatically.

Invalid selectors are rejected rather than falling back to another home:

• ~/.pi/agent
• an environment selector pointing at a Pi alias or junction
• a relative, malformed, unreadable, or oversized launcher home

Alternatives or workarounds

Users must manually edit Gentle Shell’s catalog after OpenCodex exports another client’s model set. Automating that flow without a separate target risks corrupting shared Pi configuration or silently changing the wrong installation.

Additional context

This proposal was tested locally across 342 focused assertions for path/export/refresh invariants, and the maintained source feature included focused backend, GUI, and documentation tests. The proposed change is a feature that separates target ownership while preserving the existing integration contracts.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.