# Reported issues for charlotte

Pod holds 17 of 24 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [charlotte](/mcp/charlotte).

## Most discussed

### Add video recording of browser sessions

## Summary

There is no way to record browser interactions as video. Video capture would enable debugging, documentation, and review of agent-driven automation sessions.

## Proposed Solution

Add video recording capability, either as CLI flags or as start/stop tools.

**Option A — CLI flag:**
```bash
charlotte --save-video --output-dir ./recordings
```
Records the entire session and saves on exit.

**Option B — Tools:**
- `charlotte:record_start` — begin recording
- `charlotte:record_stop` — st

[Read the thread](https://github.com/TickTockBent/charlotte/issues/21) · 2026-02-24 · open · 3 comments

### Support connecting to existing browser via CDP endpoint

## Summary

Charlotte always launches a new headless Chromium instance. There is no way to attach to an already-running browser, which prevents working with logged-in sessions, installed extensions, or shared browser state.

## Gap Reference

**GAP-33** from [Playwright MCP gap analysis](docs/playwright-mcp-gap-analysis.md). Playwright equivalent: `--cdp-endpoint` and `--extension` flags.

## Proposed Solution

Add a `--cdp-endpoint` CLI argument to BrowserManager.

**Usage:**
```bash
charlotte 

[Read the thread](https://github.com/TickTockBent/charlotte/issues/17) · 2026-02-24 · closed · 2 comments

### Epic: Test the product, not reimplementations

Umbrella for the test-suite findings from the 2026-06-09 audit: only 4 of 43 tools are exercised through their real MCP handlers; most integration tests reimplement production logic and assert the reimplementation. The silent-failure bugs (#186, #192) survived precisely because of this.

- [ ] #195 — propagate the in-memory MCP client pattern; add an end-to-end agent-flow test (highest value)
- [ ] #206 — flakiness sweep: fixed sleeps → polling, order-dependence, misplaced unit test
- [ ] #166 —

[Read the thread](https://github.com/TickTockBent/charlotte/issues/214) · 2026-06-09 · open · 1 comment

### server.json declares version 0.1.3 while npm is at 0.6.3

**Found in the 2026-06-09 deep audit.**

`server.json` (MCP registry manifest) declares `"version": "0.1.3"` in both the top level and the npm package block, while the published npm version is 0.6.3. If this file feeds `registry.modelcontextprotocol.io`, the registry advertises a four-month-old version.

**Fix:** bump both version fields to the current version and add server.json to the release checklist so it can't drift again (ideally derive it from package.json in a release script).

[Read the thread](https://github.com/TickTockBent/charlotte/issues/200) · 2026-06-09 · closed · 1 comment

### Integration suite mostly tests reimplementations, not tool handlers — only 4/43 tools exercised via MCP

**Found in the 2026-06-09 deep audit.**

Of 43 registered tools, only **4** are ever invoked through their real handlers (via in-memory MCP transport): `charlotte_fill_form`, `charlotte_dialog`, `charlotte_navigate` (once), `charlotte_observe` (once). Everything else is "tested" by reimplementing the handler's logic inside the test with raw CDP/Puppeteer calls, then asserting the reimplementation works. One test admits it outright: *"Mirrors the production clickElementByBackendNodeId function"* 

[Read the thread](https://github.com/TickTockBent/charlotte/issues/195) · 2026-06-09 · closed · 1 comment

### No upper bound on rendered output — huge pages produce multi-MB tool responses

**Found in the 2026-06-09 deep audit.**

There is no cap anywhere between the AX tree and the MCP response: `extractFullContent` (`src/renderer/content-extractor.ts:139-172`) concatenates every text node on the page; the `interactive`, `landmarks`, and `headings` arrays (`renderer-pipeline.ts:60-187`) are unbounded; `formatPageResponse` (`tool-helpers.ts:331-343`) serializes whatever it gets. A page with 100k links (long Wikipedia article, infinite-scroll feed, adversarial page) produces a multi

[Read the thread](https://github.com/TickTockBent/charlotte/issues/188) · 2026-06-09 · closed · 1 comment

### Missing Zod bounds validation on numeric tool parameters

## Description

Several tool schemas describe numeric ranges in text but don't enforce them with Zod validators:

- `src/tools/observation.ts:361` — `quality` described as "1-100" but no `.min(1).max(100)`
- `src/tools/session.ts:472-473` — viewport `width`/`height` have no min/max
- `src/tools/interaction.ts:892` — `delay` should be `>= 0`

Example:
```typescript
quality: z.number().optional().describe("1-100 for jpeg/webp quality"),
// Should be:
quality: z.number().min(1).max(100).optional().

[Read the thread](https://github.com/TickTockBent/charlotte/issues/81) · 2026-03-09 · closed · 1 comment

### Read version from package.json instead of hardcoding in server.ts

## Problem

The server version is hardcoded as a string literal in `src/server.ts` (`version: "0.4.2"`) and must be manually updated alongside `package.json` on every release. Forgetting either produces a mismatch between the npm package version and the version reported by the MCP server.

## Proposed Solution

Read the version from `package.json` at startup:

```typescript
import { readFileSync } from "fs";
import { join, dirname } from "path";
import { fileURLToPath } from "url";

const __dirn

[Read the thread](https://github.com/TickTockBent/charlotte/issues/61) · 2026-03-06 · closed · 1 comment

## Most recent

### Batch startup tool.disable() calls in createServer

## Context

Identified during review of #147 (fix for #146).

## Problem

In `src/server.ts` lines 134-138, tools not in the active profile are disabled one at a time via `tool.disable()`. Each call triggers `sendToolListChanged()` through the MCP SDK's `update()` method — the same per-tool notification flooding fixed in the meta-tool by #147.

Currently harmless at startup because `McpServer.sendToolListChanged()` has an `isConnected()` guard that drops notifications before any client connects.

[Read the thread](https://github.com/TickTockBent/charlotte/issues/148) · 2026-04-09 · closed · 0 comments

### Session/evaluate tool groups enable but tools are not callable

## Bug

After enabling the `session` and `evaluate` tool groups via `charlotte:tools`, the tools show as enabled in the response but are not actually callable by the MCP client.

## Steps to Reproduce

1. Connect Charlotte MCP server
2. Call `charlotte:tools` with `action: "enable"`, `group: "session"`
   - Response confirms: `tools_enabled: 7`, lists tools including `charlotte:set_cookies`, `charlotte:get_cookies`, etc.
3. Call `charlotte:tools` with `action: "enable"`, `group: "evaluate"`
   -

[Read the thread](https://github.com/TickTockBent/charlotte/issues/146) · 2026-04-09 · closed · 0 comments

### Add session statistics and token savings tracking

## Problem

Charlotte has strong benchmark data showing token savings vs Playwright MCP, but the server doesn't track or report savings during actual usage. Users have no visibility into the cumulative value Charlotte provides per session.

## Proposed Solution

Track per-session statistics and expose via a `charlotte:stats` tool (or session summary at disconnect):

- Total tool calls by type
- Total characters returned across all responses
- Estimated equivalent at full-page detail (what a non-

[Read the thread](https://github.com/TickTockBent/charlotte/issues/63) · 2026-03-06 · open · 0 comments

### Add end-to-end MCP protocol tests

## Problem

Current integration tests call tool helper functions directly, bypassing the MCP SDK layer (stdio transport, serialization, JSON-RPC). Protocol-level regressions (malformed responses, incorrect content type encoding, tool listing errors) would not be caught.

A Docker smoke test exists (`tests/docker-smoke-test.mjs`) but is manual and not part of CI.

## Proposed Solution

Add a test suite exercising the full MCP protocol path using `@modelcontextprotocol/sdk` client library (or `InM

[Read the thread](https://github.com/TickTockBent/charlotte/issues/60) · 2026-03-06 · closed · 0 comments

### Migrate tool names from : separator to MCP-compliant format

## Problem

Charlotte's tool names use `:` as a namespace separator (e.g., `charlotte:navigate`). The MCP specification restricts tool names to `[A-Za-z0-9_.-]`. The colon character is not allowed. MCP SDK v1.26.0+ already logs validation warnings on every tool registration.

The longer the current naming convention persists, the more documentation and user muscle memory accumulates around it, making migration harder.

## Proposed Solution

Migrate to a compliant separator. Options:

- `charlott

[Read the thread](https://github.com/TickTockBent/charlotte/issues/57) · 2026-03-06 · closed · 0 comments

### charlotte_console clear parameter fails type validation

## Bug

Calling `charlotte_console` with `clear: true` returns a validation error:

```
MCP error -32602: Input validation error: Invalid arguments for tool charlotte:console: [
  {
    "code": "invalid_type",
    "expected": "boolean",
    "received": "string",
    "path": ["clear"],
    "message": "Expected boolean, received string"
  }
]
```

## Expected Behavior

`clear: true` should clear the console log buffer and return an empty result (or confirmation).

## Likely Cause

The `clear` para

[Read the thread](https://github.com/TickTockBent/charlotte/issues/50) · 2026-03-06 · closed · 0 comments

### dialog_handled metadata test doesn't exercise the actual tool

## Problem

The "dialog_handled metadata is available after handling" test (`tests/integration/dialog.test.ts` line 377) constructs the expected `dialog_handled` shape manually from `getPendingDialogInfo()` and validates it against hardcoded strings. It never calls `charlotte:dialog` through the MCP tool registration, so the actual response payload structure (`{ dialog_handled: {...}, page: {...} }`) returned by the tool is untested.

This means:
- The JSON serialization format of `dialog_handle

[Read the thread](https://github.com/TickTockBent/charlotte/issues/34) · 2026-02-24 · closed · 0 comments

### Add full device emulation to viewport tool

## Summary

`charlotte:viewport` has device presets (`mobile`, `tablet`, `desktop`) that set viewport dimensions only. It does not configure user agent, touch support, or device pixel ratio — all of which are needed for accurate mobile testing.

## Gap Reference

**GAP-27** from [Playwright MCP gap analysis](docs/playwright-mcp-gap-analysis.md). Playwright equivalent: `--device "iPhone 15"` flag.

## Proposed Solution

Extend `charlotte:viewport` to accept named device strings and configure the 

[Read the thread](https://github.com/TickTockBent/charlotte/issues/24) · 2026-02-24 · closed · 0 comments

### Add JSON configuration file support

## Summary

Charlotte has no configuration file support. All settings are either hardcoded or set at runtime via `charlotte:configure`. Repeatable setups and CI/CD integration require a declarative config mechanism.

## Gap Reference

**GAP-38** from [Playwright MCP gap analysis](docs/playwright-mcp-gap-analysis.md). Playwright equivalent: `--config` flag loading a JSON configuration file.

## Proposed Solution

Add a `--config` CLI argument to load settings from a JSON file.

**Usage:**
```bash

[Read the thread](https://github.com/TickTockBent/charlotte/issues/19) · 2026-02-24 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/ticktockbent/charlotte/issues).