Feature request: papi.storage (or papi.ipc) read access to well-known shared locations for cross-process rendezvous

[jonathanrobie]

Problem

papi.storage currently scopes data to individual extensions. There is no way for an extension to read data written by an external companion process (a language server, AI gateway, sync daemon, etc.) because require('fs') is blocked at runtime.

The runtime error even hints at the gap:

Error: Requiring other than papi is not allowed in extensions! Rejected require('fs').
Try using papi.storage or bundling the module into your code with a build tool like webpack

papi.storage does not currently cover this use case.

Proposed Solution

Expose a sandboxed read API for a Platform.Bible-managed shared directory that external processes can write to:

// External companion process writes its endpoint info (outside Platform.Bible)
fs.writeFileSync(
  path.join(os.homedir(), '.platform.bible', 'services', 'my-service.json'),
  JSON.stringify({ port: 8432 })
);

// Extension reads it through papi (Platform.Bible handles the fs access)
const info = await papi.storage.readSharedService('my-service');
// → { port: 8432 }

Or, more broadly, a papi.storage.readPlatformFile(relativePath) that is restricted to the ~/.platform.bible/ directory.

This is related to #144 (service registry), but is a more minimal ask: just read access to a well-known directory, rather than a full registry protocol. Even a simple convention ("extensions may call papi.storage.readPlatformFile('services/<name>.json')") would be enough.

Why This Matters

Extensions that pair with a companion process (ML inference, language servers, database servers) need a way to discover that process's endpoint. Without any papi-mediated file access, the only workarounds are:

• Hardcoded ports — breaks when ports conflict
• User-configured URLs — poor UX, requires manual setup
• fetch-based port scanning — fragile, adds latency, produces spurious connection errors in logs

A papi-mediated read of a shared directory would give companion processes a standard, sandbox-compatible rendezvous point without requiring a full IPC protocol.

Context

Encountered while building paratext-copilot + llm-gateway. llm-gateway writes ~/.platform.bible/llm-gateway.port on startup; paratext-copilot cannot read it due to the fs restriction and currently falls back to port scanning.