Nostr Signer Chatgpt MCP Server

Nostr Signer for ChatGPT and Codex

A local-first, open-source signer bridge that lets ChatGPT Work or Codex request Nostr signatures from Alby, nos2x, another NIP-07 browser extension, or an advanced NIP-46 remote signer. The signer keeps the private key. This project never needs, accepts, stores, logs, or transmits an nsec.

Use the local installation for the strongest security. It keeps the approval page and session coordinator on your computer. The hosted bridge is a convenience beta: event contents, public keys, signatures, ciphertext, and relay responses transit infrastructure operated by Frontier Crown on Railway. Hosted NIP-44 encryption and decryption are disabled because plaintext could otherwise transit that infrastructure.

Release status: v0.4.0 local public beta plus a live accountless hosted alpha. Live Chrome-family NIP-07 public-key access and signing succeeded on 2026-09-10. A user-approved announcement was accepted and independently read back with a valid signature from nos.lol, nostr.mom, and relay.primal.net. The hosted MCP endpoint at https://signer.frontiercrown.com/mcp completed external initialization and two-session pairing-page isolation tests. Its reduced hosted surface exposes 17 tools and omits NIP-44 encrypt/decrypt. It is active in the official MCP Registry but has not been approved by the OpenAI directory.

Will it work for everyone?

Not universally. The current release is for desktop users who can run Node.js 22+, connect a local stdio MCP server, and open the approval page in a Chrome- or Firefox-family profile with a compatible NIP-07 extension. It is not a mobile signer or unattended signing daemon. Prefer a signer that displays the complete event—including kind, content, tags, and timestamp—before every approval.

The free local plugin is the primary, recommended public release because each user keeps the key and runs the bridge. It needs no OAuth or separate account: the browser extension supplies the Nostr public key and approves each signature. The hosted prototype also has no OAuth or user accounts: it binds each AI MCP session to an extension-enabled browser with a short-lived, high-entropy capability URL. It still needs per-session isolation, abuse controls, privacy/retention operations, and an independent security review. See LAUNCH_READINESS.md, COMPATIBILITY.md, and HOSTED_SERVICE.md.

Install in Codex

Clone the public source, verify the release tag, build it locally, and register the bundled MCP server. Then start a new Codex task so its tools are loaded:

git clone --branch v0.4.0 https://github.com/hudhaifahz/nostr-signer-chatgpt.git
cd nostr-signer-chatgpt
npm ci
npm run check
codex mcp add nostr-signer -- node "$PWD/mcp/server.mjs"

The repository includes portable plugin manifests, but a one-command Grynvault marketplace wrapper is not published yet. Inspect the source and release tag before installing; the local signer bridge runs with the permissions of the desktop user who starts it.

Download the prebuilt local bundle

The release page includes a prebuilt archive and SHA-256 checksum. It contains the standalone MCP bundle, plugin manifests, signer skill, license notices, source, tests, and documentation. It does not contain a private key, signer session, or browser data.

Build hashes and the live deployment's claimed source revision are documented in PROVENANCE.md and published at https://signer.frontiercrown.com/provenance. Tagged archives receive GitHub build provenance attestations.

curl -LO https://github.com/hudhaifahz/nostr-signer-chatgpt/releases/download/v0.4.0/nostr-signer-chatgpt-0.4.0.tgz
curl -LO https://github.com/hudhaifahz/nostr-signer-chatgpt/releases/download/v0.4.0/nostr-signer-chatgpt-0.4.0.tgz.sha256
shasum -a 256 -c nostr-signer-chatgpt-0.4.0.tgz.sha256
mkdir nostr-signer-chatgpt
tar -xzf nostr-signer-chatgpt-0.4.0.tgz -C nostr-signer-chatgpt --strip-components=1
codex mcp add nostr-signer -- node "$PWD/nostr-signer-chatgpt/mcp/server.mjs"

Expected SHA-256 for the v0.4.0 bundle: 75d2c2cc7070ce0a15dbc122c479c312919279ff4160ed9e7e1993c335ce95a5.

The ordinary-user journey

1. Install and start the plugin locally.
2. Open the local setup page at http://127.0.0.1:34846/ in the Chrome or Firefox profile where Alby, nos2x, or another NIP-07 signer is installed.
3. Click Connect browser extension once and approve public-key access in the extension. Keep this page open.
4. Ask ChatGPT or Codex to prepare a Nostr note.
5. Review the exact note. Tell ChatGPT or Codex to request the signature.
6. The local page shows the exact pending operation. Click Continue in extension, then approve in the extension if it asks.
7. Separately tell ChatGPT or Codex to publish. A post is reported live only when at least one relay acknowledges it.

To use the same signer inside a NIP-46-capable app such as Noornote or YakiHonne, connect the browser extension first, click Create app sign-in link, copy the private bunker:// link, and paste it into the app's Remote signer or Bunker login. Return to the local page to approve the exact client public key and every subsequent signing, encryption, or decryption request. The link expires, is valid for one approved client, and must be treated like a temporary password.

For Grynvault in the Codex in-app browser, open https://frontiercrown.com/portal, click Sign in with Codex signer, and ask Codex to approve the exact short code using this plugin. The portal tab keeps a separate high-entropy secret; the short code only locates the pending request. The signed authorization returns that public key's read-only account dashboard to the originating tab and does not publish an event, create an invoice, change settlement, or grant wallet custody.

Never paste an nsec, raw private key, seed phrase, or backup into ChatGPT, Codex, the setup page, or a tool call. If an nsec was exposed, rotate it in a trusted signer outside this project.

Architecture

flowchart LR
  U[User] --> C[ChatGPT Work or Codex]
  U --> E[Alby, nos2x, or NIP-07 extension]
  U --> S[Advanced NIP-46 signer]
  U --> A[Noornote, YakiHonne,
  or another NIP-46 app]
  C -->|focused MCP tools| P[Local plugin process]
  B[Local approval page\n127.0.0.1 only] <--> P
  B -->|window.nostr request| E
  E -->|signed or encrypted result| B
  P -->|NIP-46 encrypted requests| R[(Configured Nostr relays)]
  A -->|NIP-46 encrypted requests| R
  R -->|approval-gated responses| P
  R -->|NIP-46 events| S
  S -->|approve or reject| R
  P -->|verified signed event\nafter separate publish intent| R

  K[nsec] -. remains inside signer .-> E
  K -. remains inside signer .-> S

The code separates the signer interface, session/intent state, relay gateway, MCP adapter, and local UI. A future MCP Apps component, WebMCP site tool, hardware signer, or different transport can reuse the service layer without changing event-validation policy.

What is implemented

• Primary NIP-07 bridge for Alby, nos2x, and compatible extensions: one local connection, one queued approval at a time, random request IDs, stale-response rejection, and no private-key access.
• Advanced bunker:// and client-generated nostrconnect:// flows using nostr-tools NIP-46 support.
• Experimental remote-signer mode for third-party NIP-46 clients. It creates a one-client, short-lived bunker:// link, accepts both NIP-44 and legacy NIP-04 encrypted RPC transport, and requires local approval for connect, event signing, NIP-04, and NIP-44 operations.
• get_public_key, exact generic-event and kind:1 preparation, bound sign_event, nip44_encrypt, nip44_decrypt, separately confirmed publish_event, and bounded relay reads for kinds 0 and 1.
• Exact unsigned-event validation, signature/hash verification, signer-pubkey binding, one-use signing intents, timeouts, session expiry, and stale-pairing rejection.
• Per-relay publication acknowledgements. No success claim when every relay rejects or times out.
• In-memory-only signer sessions. Restarting or disconnecting forgets pairing material and prepared events.
• A localhost-only setup page with a per-process anti-CSRF token, request size limit, no external scripts, and no persistence.
• Redacted structured logs and hard rejection of nsec-like input.
• Signed Grynvault account-dashboard access plus separately prepared/confirmed supporter and 2,000-sat name@frontiercrown.com NIP-05 invoice requests. An invoice response is always reported as pending, never as payment or settlement.
• Short-lived Grynvault in-app browser handoff approval bound to the exact HTTPS URL, challenge, code, and payload hash. Only the browser holding the separate secret can claim its read-only dashboard.
• Portable Agent Plugins manifests plus the scaffolded Codex compatibility manifest.
• A deterministic safe simulated signer/relay path for CI and onboarding.

Local setup

Requirements: Node.js 22 or later and npm. Use a test Nostr identity for the public beta.

npm ci
cp .env.example .env
npm run build
npm start

Set NOSTR_RELAYS to comma-separated wss:// relay URLs before live pairing or publication. The example file contains starting values, not an availability guarantee. ws:// is rejected except for localhost/loopback test relays.

The setup page binds to and accepts only 127.0.0.1. Open it in the browser profile containing your NIP-07 extension—not the Codex in-app browser unless that browser actually has such an extension. Connect once and keep the tab open while signing. The page queues the exact request and requires a browser-side click before calling window.nostr. That interaction gate is not proof of human presence when the host also has browser automation, so the extension's own approval policy remains the final protection.

The advanced section accepts a bunker: URI only in memory and never logs it. A generated nostrconnect: URI contains an ephemeral pairing secret; treat it as sensitive and do not post it publicly.

The experimental third-party-app section makes this plugin act as the remote signer. Its generated bunker:// link is shown only on the loopback page and is not exposed as an MCP tool. One client can be connected at a time. Stopping the bridge, restarting the process, or reaching the session expiry invalidates that app connection; reconnect the app with a new link.

Local demo

The safe onboarding demo exercises prepare → sign → verify → publish entirely in memory:

npm run demo

The output includes a simulated public key, event ID, and relay acknowledgement. It does not prove compatibility with a live signer or public relay.

To inspect the real MCP tool surface locally:

npm run build
npx @modelcontextprotocol/inspector node mcp/server.mjs

To connect this checkout directly to a local Codex host without installing a marketplace package:

codex mcp add nostr-signer -- node /absolute/path/to/nostr-signer-chatgpt/mcp/server.mjs

Then restart the ChatGPT desktop app/Codex host and use /mcp or MCP settings to verify the server. For a packaged install, use the included plugin.json, mcp.json, .codex-plugin/plugin.json, .mcp.json, skill, and committed mcp/server.mjs bundle in a local marketplace. The current OpenAI documentation distinguishes local Codex stdio support from ChatGPT web. The accountless hosted alpha is available at https://signer.frontiercrown.com/mcp; it uses short-lived capability sessions rather than OAuth.

OpenClaw currently documents support for Agent Plugin/Codex bundles. After downloading and unpacking the release, install the local directory (or the release archive, if your OpenClaw version accepts it), inspect the plugin, and restart OpenClaw:

openclaw plugins install /absolute/path/to/nostr-signer-chatgpt
openclaw plugins inspect nostr-signer-chatgpt

This package has the required bundle layout, but an OpenClaw installation was not available in this validation environment. Treat it as intended compatibility until the live install, tool discovery, and signer round-trip are captured in COMPATIBILITY.md.

Relevant OpenAI guidance: plugin packaging, connecting and testing, and Codex MCP configuration.

Example conversation

You: Connect my signer safely.

Assistant: Open the local setup URL in the browser profile where Alby or nos2x is installed, click Connect browser extension, and approve public-key access. I will wait for the signer status to become connected.

You: Prepare “Hello Nostr” as a note.

Assistant: Here is the exact kind:1 event preview. It is not signed or published. Should I request its signature?

You: Yes, request the signature.

Assistant: The exact request is waiting on the local page. Click Continue in extension, then approve in the extension. The verified event will remain signed but not published until you separately tell me to publish.

You: Publish it.

Assistant: Relay A accepted the event; Relay B timed out. The event is live on at least Relay A.

Tools and safety gates

Grynvault integration

Grynvault authorization uses a fresh kind 27235 Nostr HTTP-auth event bound to the exact HTTPS URL, POST method, server challenge, and SHA-256 hash of the exact JSON body. The same NIP-07/NIP-46 signer and signature-verification pipeline is used; the resulting authorization is sent only to the fixed Grynvault production API origin.

Supporter membership and paid NIP-05 remain different products. A one-time supporter donation can be 21 through 1,000,000 sats, the optional 30-day plan is 2,100 sats, and a name@frontiercrown.com invoice is 2,000 sats. Creating an invoice does not pay it. A checkout URL, browser redirect, or pending response does not activate a supporter entitlement or NIP-05 identifier; only separately verified BTCPay settlement can do that.

Production v117 is live at commit 7517fea8fe2a46ee96321e2ba694e91f781a4fc0. A live in-app browser handoff approved the exact signed request and returned the originating tab's dashboard for pubkey 0ab377…9b5bd; the portal then displayed account, Drive, Arkade, NIP-05, and settled-payment status. No invoice was created, no Nostr event was published, and no settlement changed during that test.

See GRYNVAULT_INTEGRATION.md for the exact MCP inputs, HTTP bodies, and signature tags.

Signer status

“Intended” is not a compatibility claim. Record signer/version, pairing mode, relay set, requested method, approval UI, returned event verification, and publication acknowledgement before changing a signer to “tested.”

How the NIP-07 bridge works

NIP-07 defines window.nostr.getPublicKey(), window.nostr.signEvent(), and optional encryption methods for browser pages. The plugin does not inject or impersonate an extension. Its loopback page detects the API supplied by an installed signer, sends one reviewed request to it, and returns the result to the same verification pipeline used by NIP-46. The NIP-07 specification defines the standard interface.

The extension decides whether to prompt, approve, or reject. Use a signer that displays the complete event before every approval; do not approve from a generic “sign” prompt when the event cannot be inspected. Multiple installed signer extensions can contend for window.nostr; use a dedicated browser profile if selection is ambiguous.

Why there is no private-key fallback

GitHub and Cloudflare secret stores protect values at rest, but signing code must recover usable key material at runtime. That would turn this plugin into a remotely custodial hot signer and expand signing authority to deployment credentials, operators, and any compromised runtime. Local encrypted storage has the same runtime-unlock problem. This project therefore keeps the private key in the user's extension or remote signer.

Troubleshooting

• No relays are configured: copy .env.example to .env, or provide relays to the pairing tool. The included start command loads .env when it exists.
• No extension is detected: copy the setup URL into the Chrome or Firefox profile where Alby or nos2x is installed and unlocked, then reload the page. The Codex in-app browser normally does not share those extensions.
• More than one extension is installed: disable the unwanted signer for this site or use a browser profile with only the intended extension.
• A request is waiting: keep the setup page open, review the displayed operation, click Continue in extension, and complete any extension prompt. Do not silently retry after a timeout.
• Pairing stays pending: verify the exact relay set is reachable by both client and signer, approve in the signer, and retry with a fresh URI after five minutes. Pairing URIs are one-session secrets.
• Signer request times out: check signer connectivity and relay reachability. Prepare a new event; do not silently retry an ambiguous signing request.
• All publish acknowledgements fail: the signed event is retained for an explicit retry during the same session. Check relay policy, authentication requirements, and network access.
• Setup page will not start: another process may own port 34846. Set NOSTR_SETUP_PORT to a free local port.
• ChatGPT web cannot reach the server: stdio is local-host only. Use a reviewed Secure MCP Tunnel for development or deploy an authenticated streamable-HTTP server before hosted use.

Developer commands

See VALIDATION.md for the exact local evidence and its limits.

Limitations and roadmap

• One live Brave NIP-07 flow and exact Grynvault handoff passed, but the extension name/version was not captured. Named Alby, nos2x, NIP-46 signer, and relay-specific compatibility is not yet proven.
• Sessions are deliberately non-persistent; reconnect after every process restart or expiry.
• The NIP-07 browser tab must remain open because browser extensions expose window.nostr only to browser pages.
• An MCP Apps iframe is not used for signing because it does not automatically inherit the user's ordinary browser extensions or their permission model.
• Signer auth_url challenges are not surfaced in v0.4.0; NIP-46 signers that rely on them may not complete pairing.
• NIP-46 relay authentication, dynamic relay switching, offline queues, simultaneous third-party-client sessions, multi-account selection, and automatic event discovery are not included.
• ChatGPT Work/web needs a deployed remote HTTPS MCP transport, privacy disclosures, and workspace/public review. The hosted beta intentionally uses accountless capability sessions instead of OAuth.
• Noornote v1.5.3 and YakiHonne web both completed live remote-signer login in the Codex in-app browser. No post, follow, direct message, encryption request, or publication was attempted, so those operations remain unverified on the named clients.
• The v117 Grynvault browser handoff is live and proven. Supporter/NIP-05 creation was not called during the handoff test, so no invoice or payment was created.
• Future work: replace the mutable hosted approval webpage with an auditable browser extension or signed local companion so the operator cannot silently change approval-page code; add a real compatibility matrix, verified OpenClaw install, and optional hardware-backed local signer adapter that never exports a key.

License

Apache License 2.0. It is permissive for broad reuse while adding an explicit patent grant and preserving license/notice obligations—useful for a security-sensitive interoperability project that may attract multiple implementations.

Contributing and security

Read CONTRIBUTING.md, SECURITY.md, DECISIONS.md, COMPATIBILITY.md, LAUNCH_READINESS.md, MARKETPLACE_CHECKLIST.md, and THIRD_PARTY_NOTICES.md before changing protocol, trust-boundary, packaging, or dependency code. Public launch drafts are in LAUNCH_KIT.md; they have not been posted.