Feature Summary
Users may deploy customized or forked versions of the PI agent that retain similar behavior, structure, or configuration patterns as the original PI agent.
Currently, the Emdash agent detection feature only targets official PI agent identifiers. As a result, forked or rebranded PI-based agents are not detected during endpoint discovery and agent inventory collection.
This feature request proposes extending the existing PI detection capability to support PI-derived agents such as oh-my-pi and similar implementations that are still based on pi-core-agent.
Problem or Use Case
When deploying customized, forked, or rebranded PI agents, the current detection logic fails to identify these agents because detection is limited to official PI naming and identifiers.
This creates visibility gaps where active agents may exist on clients but are not properly recognized or classified by Emdash.
Currently, Emdash primarily detects providers using predefined installation/root folders such as:
~/.pi
~/.factory
~/.codex
This approach does not scale well for forked or customized agents because many PI-derived agents use different installation paths (for example ~/.omp for oh-my-pi) while still sharing the same pi-core-agent architecture and CLI behavior.
Proposed Solution
Instead of relying only on static root-folder matching, Emdash should support a layered provider detection strategy:
- CLI-Based Detection (Primary)
Detect providers through executable/CLI metadata instead of folder names only.
Examples:
executable name
package metadata
--version output
provider-specific help output
npm package identifiers
binary signatures
This aligns with Emdash’s existing provider registry architecture where providers are already defined through CLI commands and version checks.
- Custom Provider Path Declaration
In addition to automatic provider detection, Emdash should support user-defined custom detection paths for providers and provider forks.
This would allow users to explicitly register non-standard installation directories for custom or forked agents.
Alternatives Considered
No response
Additional Context
No response
Feature Summary
Users may deploy customized or forked versions of the PI agent that retain similar behavior, structure, or configuration patterns as the original PI agent.
Currently, the Emdash agent detection feature only targets official PI agent identifiers. As a result, forked or rebranded PI-based agents are not detected during endpoint discovery and agent inventory collection.
This feature request proposes extending the existing PI detection capability to support PI-derived agents such as oh-my-pi and similar implementations that are still based on pi-core-agent.
Problem or Use Case
When deploying customized, forked, or rebranded PI agents, the current detection logic fails to identify these agents because detection is limited to official PI naming and identifiers.
This creates visibility gaps where active agents may exist on clients but are not properly recognized or classified by Emdash.
Currently, Emdash primarily detects providers using predefined installation/root folders such as:
~/.pi
~/.factory
~/.codex
This approach does not scale well for forked or customized agents because many PI-derived agents use different installation paths (for example ~/.omp for oh-my-pi) while still sharing the same pi-core-agent architecture and CLI behavior.
Proposed Solution
Instead of relying only on static root-folder matching, Emdash should support a layered provider detection strategy:
Detect providers through executable/CLI metadata instead of folder names only.
Examples:
executable name
package metadata
--version output
provider-specific help output
npm package identifiers
binary signatures
This aligns with Emdash’s existing provider registry architecture where providers are already defined through CLI commands and version checks.
In addition to automatic provider detection, Emdash should support user-defined custom detection paths for providers and provider forks.
This would allow users to explicitly register non-standard installation directories for custom or forked agents.
Alternatives Considered
No response
Additional Context
No response