Connect ChatGPT to your self-hosted MCP memory server.

Architecture · private side starts the connection

A narrow route into the Keep—not a public door.

ChatGPT cannot launch a local stdio process on your server. Secure MCP Tunnel gives it an OpenAI-hosted endpoint while tunnel-client, running inside your boundary, polls for work and forwards each request to Firekeep locally.

Network boundary: no public inbound port opens on the Keep host. Data boundary: the MCP requests and responses carried by the tunnel pass through OpenAI's control plane.

Native memory · shared organizational knowledge

Use ChatGPT's own memory and a shared Keep for different jobs.

Every solved problem can make the next one easier. ChatGPT can explicitly preserve useful experience with memory_learn; another connected agent can recall it later. For one person, that means less re-explaining. For a group, it means context can become shared organizational knowledge instead of staying inside one chat.

Before you start

Bring one healthy Keep, tunnel permissions, and ChatGPT developer-mode access.

Plan availability, workspace policy, and interface labels can change. Check OpenAI's current permissions guidance rather than relying on a saved screenshot.

Setup · Linux and systemd

Connect ChatGPT to Firekeep in five deliberate steps.

Run these commands in Bash while logged in as the same Linux account that installed and enrolled Firekeep. The service unit below pins that account and its home directory explicitly. You will need sudo to install the binary and system service.

1. Verify Firekeep for the service account.

   On the Keep host, install or enroll the Client Kit for the current account if needed. Confirm version 1.4.0 or later, then verify the complete path.

   Keep host · BashCopy

   $ if ! command -v firekeep >/dev/null 2>&1; then curl -fsSL https://firekeep.ai/latest/install | sh fi $ firekeep version $ firekeep doctor

   Already enrolled and green on 1.4.0 or later? Keep that installation. If firekeep version reports an older release, run firekeep update, then repeat the version and doctor checks before continuing.

2. Install OpenAI's tunnel client.

   Download the current tunnel-client for your architecture from OpenAI's release page, verify its published checksum, and place the binary on the path.

   verified binaryCopy

   $ sudo install -m 0755 tunnel-client /usr/local/bin/tunnel-client $ tunnel-client --version

   Download the latest tunnel-client · Inspect the curated gateway source

3. Create a fail-closed gateway wrapper and tunnel profile.

   Create a tunnel in OpenAI Platform settings. This block writes the small gateway wrapper locally, stores the runtime key in a service-account-owned 0600 file, initializes the profile, and validates the route before enabling the service.

   wrapper + profile + doctor · BashCopy

   $ FIREKEEP_OS_USER="$(id -un)" $ FIREKEEP_OS_GROUP="$(id -gn)" $ sudo install -d -m 0750 -o "$FIREKEEP_OS_USER" -g "$FIREKEEP_OS_GROUP" /etc/firekeep/chatgpt-tunnel $ sudo tee /etc/firekeep/chatgpt-tunnel/run-gateway.sh >/dev/null <<'EOF' #!/usr/bin/env bash set -euo pipefail unset FIREKEEP_TOOLS_ALLOW export FIREKEEP_TOOLSET=chat exec "$HOME/.firekeep/shims/firekeep" gateway --runtime chatgpt EOF $ sudo chmod 0755 /etc/firekeep/chatgpt-tunnel/run-gateway.sh $ sudo install -m 0600 -o "$FIREKEEP_OS_USER" -g "$FIREKEEP_OS_GROUP" \ /dev/null /etc/firekeep/chatgpt-tunnel/tunnel.env $ read -rp 'OpenAI tunnel ID: ' FIREKEEP_TUNNEL_ID $ read -rsp 'OpenAI tunnel runtime key: ' CONTROL_PLANE_API_KEY; printf '\n' $ export CONTROL_PLANE_API_KEY $ printf 'CONTROL_PLANE_API_KEY=%s\n' "$CONTROL_PLANE_API_KEY" \ | sudo tee /etc/firekeep/chatgpt-tunnel/tunnel.env >/dev/null $ cd /etc/firekeep/chatgpt-tunnel $ tunnel-client init --sample sample_mcp_stdio_local --profile firekeep \ --tunnel-id "$FIREKEEP_TUNNEL_ID" \ --mcp-command "/etc/firekeep/chatgpt-tunnel/run-gateway.sh" $ tunnel-client doctor --profile firekeep --explain $ unset CONTROL_PLANE_API_KEY FIREKEEP_TUNNEL_ID

4. Pin the enrolled OS account and enable the long-lived service.

   Run this from the same login. The generated unit names the current user, group, and home directory instead of relying on systemd's root defaults.

   systemd serviceCopy

   $ FIREKEEP_OS_USER="$(id -un)" $ FIREKEEP_OS_GROUP="$(id -gn)" $ FIREKEEP_HOME="$HOME" $ sudo tee /etc/systemd/system/firekeep-chatgpt-tunnel.service >/dev/null <<EOF [Unit] Description=Firekeep ChatGPT tunnel After=network-online.target Wants=network-online.target [Service] User=$FIREKEEP_OS_USER Group=$FIREKEEP_OS_GROUP Environment="HOME=$FIREKEEP_HOME" WorkingDirectory=/etc/firekeep/chatgpt-tunnel EnvironmentFile=/etc/firekeep/chatgpt-tunnel/tunnel.env ExecStart=/usr/local/bin/tunnel-client run --profile firekeep Restart=always RestartSec=5 [Install] WantedBy=multi-user.target EOF $ sudo systemd-analyze verify /etc/systemd/system/firekeep-chatgpt-tunnel.service $ sudo systemctl daemon-reload $ sudo systemctl enable --now firekeep-chatgpt-tunnel $ sudo systemctl status firekeep-chatgpt-tunnel

5. Associate the tunnel, add it in ChatGPT, and prove the handoff.

   Associate the tunnel with the target ChatGPT workspace in Platform settings. Enable developer mode, open ChatGPT Plugins, and choose + to create a developer-mode app. Under Connection, choose Tunnel, select or paste the tunnel_id, review the discovered tools, and start a new conversation with the connection enabled.

   First ask ChatGPT to call firekeep_gateway_status. Then ask it to use memory_recall for a known, non-secret fact. For a cross-runtime proof, explicitly save a harmless, clearly labeled test memory in ChatGPT and recall it from Claude Code or Codex.

Curated chat surface

Enough to remember and continue. Deliberately smaller than the full gateway.

With every backend healthy, the chat preset exposes up to twelve Firekeep work tools, plus the always-present local firekeep_gateway_status diagnostic. A degraded backend can reduce the work-tool count; status remains available. ChatGPT receives instructions written for this reduced surface.

• memory_recallFind relevant team knowledge.
• memory_learnPreserve a useful fact or fix.
• memory_feedbackReport whether recalled knowledge held.
• skill_recallFind a reusable procedure.
• skill_listList available procedures.
• ctx_start_sessionOpen work with prior context.
• ctx_updateRecord decisions and progress.
• ctx_complete_sessionClose work with an outcome.
• ctx_abandon_sessionEnd work that will not continue.
• ctx_list_sessionsSee active and recent sessions.
• ctx_resume_sessionContinue an earlier session.
• ctx_get_shadowRecover summarized session context.

Not on this route: vault access, corpus ingest, Relay coordination, backups, dex/code tools, policy actions, and decision boards. Those tools are absent from the tunnel-facing gateway rather than hidden by prompt wording. Corpus ingestion is excluded, but memory_recall can still return existing corpus content visible to the enrolled member, including that member's private Docdex or Maildex material. The toolset is a capability allowlist, not a per-memory or per-document content filter.

Clear operating boundary

Know what stays private, what crosses the tunnel, and what remains explicit.

Operate and stop it cleanly

Three commands cover the normal runbook.

Go deeper

Build the Keep first. Then connect the agents that should share it.