🎯 Use case
This file lives under “utils/”, which covers cross-cutting helpers (shell, tempfiles, settings, messages, process input, …). On the API surface it exposes parseAddress — mainly functions, hooks, or classes. What the file header says: Peer address parsing — kept separate from peerRegistry.ts so that SendMessageTool can import parseAddress without transitively loading the bridge (axios) and UDS (fs, net) modules at tool-enumeration time.
Generated from folder role, exports, dependency roots, and inline comments — not hand-reviewed for every path.
🧠 Inline summary
Peer address parsing — kept separate from peerRegistry.ts so that SendMessageTool can import parseAddress without transitively loading the bridge (axios) and UDS (fs, net) modules at tool-enumeration time.
📤 Exports (heuristic)
parseAddress
🖥️ Source preview
/**
* Peer address parsing — kept separate from peerRegistry.ts so that
* SendMessageTool can import parseAddress without transitively loading
* the bridge (axios) and UDS (fs, net) modules at tool-enumeration time.
*/
/** Parse a URI-style address into scheme + target. */
export function parseAddress(to: string): {
scheme: 'uds' | 'bridge' | 'other'
target: string
} {
if (to.startsWith('uds:')) return { scheme: 'uds', target: to.slice(4) }
if (to.startsWith('bridge:')) return { scheme: 'bridge', target: to.slice(7) }
// Legacy: old-code UDS senders emit bare socket paths in from=; route them
// through the UDS branch so replies aren't silently dropped into teammate
// routing. (No bare-session-ID fallback — bridge messaging is new enough
// that no old senders exist, and the prefix would hijack teammate names
// like session_manager.)
if (to.startsWith('/')) return { scheme: 'uds', target: to }
return { scheme: 'other', target: to }
}