hermes - 💡(How to fix) Fix MCP approvals subsystem (permissions_list_open / permissions_respond) lacks gateway IPC and is non-functional

Bug

The MCP bridge surfaces two approval tools that cannot work end-to-end:

1. permissions_list_open always returns {"count": 0, "approvals": []}. EventBridge._pending_approvals (mcp_serve.py:221) is never populated — no code path adds entries to it. The poll loop only enqueues message-type events.

2. permissions_respond only mutates the bridge subprocess's local dict and emits a local approval_resolved event. It does not IPC the decision back to the gateway, so the originating exec/plugin approval request remains pending. Docstring acknowledges "best-effort without gateway IPC" (mcp_serve.py:305).

Root cause

Both gaps stem from the same architectural property: the MCP bridge runs as an independent stdio subprocess and reads shared state files (state.db, sessions.json) but has no bidirectional channel to the gateway process. Approvals are inherently request/response, so the file-watching pattern that works for messages can't carry them.

What "fixed" would look like

• Inbound: gateway publishes pending approvals to a location the bridge can observe (e.g. dedicated table in state.db with a flag column, or a Unix socket the bridge connects to).
• Outbound: bridge sends decisions back via the same channel; gateway resolves the approval as if it came from the local UI.

Either an IPC primitive (socket / named pipe) or an in-DB queue would work. The docstring suggests the maintainers have already considered this.

Affected versions

origin/main at 04918345ea31b1106d2ee6d4f42822f4f57616ee. Confirmed by reading mcp_serve.py lines 221, 296-319, 821-857.