Skip to main content
Glama
README.md
# 2Bot

**2Bot** is a FastMCP server that lets ChatGPT (or any MCP client) call your local Codex CLI through a controlled MCP tool.

- MCP server name is fixed to **`2Bot`**.
- Local mode uses **stdio**.
- Remote mode uses **HTTP (Streamable HTTP)** for ChatGPT-compatible deployments.

## What 2Bot does

2Bot exposes a single typed tool, `run_codex_prompt`, which runs `codex exec --json -` safely:

- no `shell=True`
- prompt passed via stdin
- timeout handling
- working-directory validation and allowlist support
- JSON-serializable structured output

## Installation

```bash
python -m venv .venv
source .venv/bin/activate
pip install -e .
```

For tests:

```bash
pip install -e .[dev]
pytest
```

## Configuration

2Bot is environment-driven.

| Variable | Default | Description |
|---|---|---|
| `TWOBOT_TRANSPORT` | `stdio` | `stdio` or `http` |
| `TWOBOT_HOST` | `127.0.0.1` | HTTP bind host |
| `TWOBOT_PORT` | `9000` | HTTP bind port |
| `TWOBOT_BASE_URL` | unset | Optional public HTTPS URL for docs/ops |
| `TWOBOT_LOG_LEVEL` | `INFO` | Logging level |
| `TWOBOT_ENABLE_NO_AUTH` | `true` | Enable no-auth mode for initial ChatGPT testing |
| `CODEX_ALLOWED_ROOTS` | unset | Optional cwd allowlist (`:`-separated on macOS/Linux) |

> Authentication note: for first connection tests, use **no auth**. For production, prefer standards-based MCP-compatible auth in front of or integrated with this service.

## Local mode (stdio)

Run with stdio (default):

```bash
2bot-mcp
# or
python -m twobot_codex_mcp.server
```

You can also force stdio:

```bash
TWOBOT_TRANSPORT=stdio 2bot-mcp
```

## Remote mode (HTTP / Streamable HTTP)

Run HTTP mode locally on loopback:

```bash
TWOBOT_TRANSPORT=http TWOBOT_HOST=127.0.0.1 TWOBOT_PORT=9000 2bot-mcp
```

Or with explicit CLI flags:

```bash
2bot-mcp --transport http --host 127.0.0.1 --port 9000
```

### Expose via HTTPS for ChatGPT

ChatGPT must reach a public HTTPS URL. Typical setup:

1. Run 2Bot in HTTP mode on `127.0.0.1:9000`.
2. Put a reverse proxy or tunnel in front (Nginx, Caddy, Cloudflare Tunnel, etc.).
3. Publish a TLS endpoint like `https://mcp.example.com` forwarding to `http://127.0.0.1:9000`.
4. Configure ChatGPT custom MCP connection to that public URL.

## ChatGPT connection notes

ChatGPT connects to the **remote HTTPS MCP endpoint**, not to stdio.

High-level flow:

1. Start 2Bot in HTTP mode.
2. Expose the endpoint at a public HTTPS URL.
3. Create/connect the custom MCP app in ChatGPT pointing at that URL.

Use URL pattern:

- **`https://<your-public-hostname>/`** (or the exact path your reverse proxy maps to the FastMCP HTTP app)

## Security notes (important)

Exposing a tool that can execute local Codex workflows is sensitive.

Recommendations:

- Restrict `CODEX_ALLOWED_ROOTS` to minimal directories.
- Keep conservative defaults (`sandbox=read-only`, `allow_edits=false`).
- Avoid `danger-full-access` unless absolutely necessary and trusted.
- Prefer private deployments (VPN, private network, authenticated gateway).
- Do not expose an unrestricted instance on the public internet casually.

## Example deployment notes

### 1) Local-only HTTP bind

```bash
TWOBOT_TRANSPORT=http TWOBOT_HOST=127.0.0.1 TWOBOT_PORT=9000 2bot-mcp
```

### 2) Reverse proxy / tunnel

- Proxy `https://mcp.example.com` -> `http://127.0.0.1:9000`
- Keep TLS at the edge
- Keep 2Bot private behind the proxy where possible

### 3) Keep stdio mode for local MCP clients

```bash
TWOBOT_TRANSPORT=stdio 2bot-mcp
```

## Tool reference: `run_codex_prompt`

Parameters:

- `prompt: str`
- `cwd: str | None = None`
- `model: str | None = None`
- `profile: str | None = None`
- `sandbox: "read-only" | "workspace-write" | "danger-full-access" = "read-only"`
- `approval_policy: "untrusted" | "on-request" | "never" | None = None`
- `allow_edits: bool = False`
- `skip_git_repo_check: bool = False`
- `add_dirs: list[str] | None = None`
- `timeout_sec: int = 1800`
- `ephemeral: bool = True`
- `include_event_log: bool = False`

Behavior is preserved from local mode while adding transport/config flexibility.

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is zero ambiguity—no other tools exist to confuse with run_codex_prompt. The tool's purpose is distinct by default.

Naming Consistency5/5

The single tool name 'run_codex_prompt' follows a clean verb_noun pattern, making it clear and predictable. With only one tool, consistency is inherently maintained.

Tool Count2/5

A single tool is extremely thin for an MCP server, even for a narrow purpose. While it might serve a specific need, it feels like a minimal wrapper rather than a coherent tool set, earning a low score.

Completeness3/5

The tool covers the basic action of running a codex prompt, but the surface is incomplete—no ability to list past runs, check status, cancel, or configure the CLI. For the implied domain, notable operations are missing.

Maintenance

ActivityInactive
ResponsivenessNo issues