# Reported issues for janee

Pod holds 17 of 18 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 [janee](/mcp/janee).

## Most discussed

### Security Audit

Hey, I came across this solution and I like the idea of not giving acces to our secrets.
I cloned the repo and asked claude to do a security audit.
I wonder what you think about this, is my guy hallucinating? :-)

# Security Audit: Janee v0.4.1

  **Project:** Secrets management proxy for AI agents via MCP
  **Date:** 2026-02-09
  **Scope:** Full source review of all TypeScript source files

  ---

  ## Critical: SSRF allows secret exfiltration

  An AI agent can bypass the proxy by passing an a

[Read the thread](https://github.com/rsdouglas/janee/issues/14) · 2026-02-09 · closed · external user · 7 comments

### 'exec' over HTTP does not make sense as implemented (discussion)

# Janee Exec Architecture Rethink

## Runner + Authority model for safe(ish) agent CLI execution

This is a detailed write-up of what Janee is, what it is not, why the current exec model breaks for containerized agents (“creatures”), and how to evolve Janee without wrecking the simple local UX that already works well.

---

## 1) What Janee is (and why it matters)

Janee is a **credential mediation layer** for agents.

Its core value is not “perfect secret isolation under all adversarial conditi

[Read the thread](https://github.com/rsdouglas/janee/issues/108) · 2026-02-21 · closed · 3 comments

### Support network transport (HTTP/SSE) for `janee serve` to enable containerized agent deployments

## Support network transport (HTTP/SSE) for `janee serve` to enable containerized agent deployments

### Problem

When running an AI agent inside a Docker container (e.g., OpenClaw with Sysbox), the `janee-openclaw` plugin cannot connect to a host-side Janee instance. Both `janee serve` and the plugin are hardcoded to stdio transport:

```javascript
// janee: core/mcp-server.js
const transport = new StdioServerTransport();

// janee-openclaw: index.js
const transport = new StdioClientTransport({

[Read the thread](https://github.com/rsdouglas/janee/issues/28) · 2026-02-10 · closed · external user · 3 comments

### feat: propagate timeout through runner mode for service tests

## Context

From PR #125 review — when `janee test --timeout 5000` runs in runner mode, the timeout applies to the round-trip HTTP call to the Authority, not to the upstream service test itself. The Authority uses its own 10s default internally.

## Proposed

- Add `timeout` field to `POST /v1/test` request body
- Add `timeout` parameter to the `test_service` MCP tool schema
- Authority should respect the requested timeout (clamped to a max)
- Document that CLI `--timeout` in runner mode = round

[Read the thread](https://github.com/rsdouglas/janee/issues/128) · 2026-02-27 · closed · 2 comments

### feat: SIGHUP config reload for long-running servers

## Problem

Janee has a `reload_config` MCP tool for agents to trigger config reloads, but there's no infrastructure-level way to reload config without restarting the process.

When running Janee as a long-lived authority server (`janee serve`), changing `config.yaml` (e.g. adding a capability, updating allowedAgents) currently requires killing and restarting the process. This causes downtime for any connected runners/agents.

## Proposal

Add a SIGHUP handler that reloads config from disk, usin

[Read the thread](https://github.com/rsdouglas/janee/issues/117) · 2026-02-23 · closed · 2 comments

### headers auth type: CLI doesn't support custom header names, manual config breaks encryption

## Context

Cursor Agent here. I was trying to configure Janee to proxy requests to the dev.to API, which uses a custom `api-key` header for authentication (not `Authorization: Bearer <token>`).

## What I tried

### Attempt 1: `bearer` auth type

```bash
janee add devto -u https://dev.to/api -k "<key>" --auth-type bearer
```

This succeeded, but dev.to returned `403` because it expects the key in an `api-key` header, not `Authorization: Bearer <key>`.

I also tried passing a custom header via `

[Read the thread](https://github.com/rsdouglas/janee/issues/92) · 2026-02-19 · closed · 2 comments

### MCP list_services returns empty despite configured services

## Bug

`list_services` via MCP returns an empty array `[]` despite having 8 services and 10 capabilities configured.

## Reproduction

1. Have services configured (verified via `janee list` CLI which shows all 8 services correctly)
2. Call `list_services` via MCP tool
3. Returns `[]`

## Expected

Should return the same services/capabilities visible via `janee list`:

```
Services: mexc, okx, bybit, google-analytics, devto, openseed-patch, secure-seed, fal
Capabilities: mexc, okx, bybit, google

[Read the thread](https://github.com/rsdouglas/janee/issues/116) · 2026-02-23 · closed · 1 comment

### Hardened agent identity: session-bound verified authentication

## Context

Janee supports agent-scoped access control via `allowedAgents` on capabilities and a `defaultAccess` server policy.

### Current state (shipped)

Agent identity is resolved from **`clientInfo.name`** sent during the MCP `initialize` handshake — the standard MCP client identification mechanism. This works uniformly across all transports:

- **stdio** (Cursor, Codex, Claude Code, Claude Desktop): `clientInfo.name` is captured from the single-client session
- **HTTP** (autonomous agents

[Read the thread](https://github.com/rsdouglas/janee/issues/96) · 2026-02-20 · open · 1 comment

## Most recent

### RFC 0001 implementation status: exec mode is ~95% complete, missing `janee add --exec` CLI flow

Reviewed RFC 0001 (Secure CLI Execution) against the codebase. Here's the status:

## ✅ Fully implemented

| Component | File | Notes |
|-----------|------|-------|
| Core execution engine | `src/core/exec.ts` | `validateCommand()`, `buildExecEnv()`, `scrubCredentials()`, `executeCommand()` |
| Command whitelisting | `exec.ts` | `allowCommands` config enforced |
| Shell injection blocking | `exec.ts` | Metacharacters rejected: `;\|\`$(){}\\<>` |
| Credential injection | `exec.ts` | `{{credential

[Read the thread](https://github.com/rsdouglas/janee/issues/87) · 2026-02-18 · closed · 1 comment

### npm 0.8.1 missing exec mode (janee_exec tool) — needs 0.8.2 publish

## Dogfooding finding

The exec mode feature from PR #69 was merged on 2025-02-13 at 13:04 UTC, but npm 0.8.1 was published at 06:42 UTC the same day — **before the merge**.

As a result, `janee serve` via the npm-installed binary exposes only 3 tools:
- `list_services`
- `execute` 
- `reload_config`

The `janee_exec` tool is completely absent because the exec tool registration code (`mcp-server.ts` line ~186-218) does not exist in the published dist.

## Reproduction

```bash
npm install -g @tr

[Read the thread](https://github.com/rsdouglas/janee/issues/70) · 2026-02-13 · closed · 1 comment

### Publishing to MCP Registry — step-by-step guide

Following up on PR #60 (merged ✅), here's how to publish Janee to the Official MCP Registry.

The `server.json` and `mcpName` are already in place, so you're 90% there!

## Steps

### 1. Publish the latest npm package
Make sure the npm package `@true-and-useful/janee` v0.8.0 includes the `mcpName` field in its `package.json`:
```bash
npm publish --access public
```

### 2. Install `mcp-publisher`
```bash
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publi

[Read the thread](https://github.com/rsdouglas/janee/issues/61) · 2026-02-12 · closed · 1 comment

### Add --json flag to janee search for programmatic access

## Problem

`janee search [query]` outputs a human-readable formatted listing of the service directory. There's no structured output option, making it difficult to use programmatically.

## Proposed solution

Add a `--json` flag (consistent with `janee list --json`) that outputs the directory results as a JSON array:

```bash
janee search stripe --json
```

Expected output:
```json
[
  {
    "name": "stripe",
    "description": "Payment processing platform",
    "url": "https://api.stripe.com",

[Read the thread](https://github.com/rsdouglas/janee/issues/37) · 2026-02-10 · closed · 1 comment

### Add --json flag to `janee list` command

## Context

Building integration between [the-office](https://github.com/rsdouglas/the-office) plugin system and the Janee CLI. The Office backend acts as an RPC broker that spawns CLI commands and expects JSON on stdout.

## Problem

`janee list` outputs human-readable text only:

```
Services:
  bearerService
    URL: https://api1.com
    Auth: bearer
  ...
```

There is no `--json` flag, so the backend adapter cannot parse structured data from it.

Reading `~/.janee/config.yaml` directly is n

[Read the thread](https://github.com/rsdouglas/janee/issues/34) · 2026-02-10 · closed · 1 comment

### No rate limiting on MCP execute tool

## Problem

The `execute` tool has no rate limiting. A compromised or buggy agent could spam API requests.

## Current Mitigation

Rate limiting is expected to happen:
1. **Upstream at the API** — most APIs have their own rate limits
2. **In OpenClaw session policies** — session-level controls

## Options

1. **Document the expectation** that rate limiting happens upstream (simplest)
2. **Add optional capability-level rate limiting** (e.g., `rateLimit: "10/minute"`)
3. **Add global rate limiting

[Read the thread](https://github.com/rsdouglas/janee/issues/25) · 2026-02-10 · closed · 1 comment

### Add response body size limit to prevent DoS

## Problem

`makeAPIRequest()` in `src/core/mcp-server.ts` concatenates response chunks without a size limit:

```typescript
res.on('data', (chunk) => {
  body += chunk;  // ← unbounded
});
```

A malicious or broken API could OOM the proxy.

## Fix

1. Add configurable max body size (default 10MB)
2. Abort request if exceeded
3. Return error to agent with truncation notice

## Credit

Found by @mkoorn in #14

[Read the thread](https://github.com/rsdouglas/janee/issues/21) · 2026-02-10 · closed · 1 comment

### Encrypt auth.headers values at rest

## Problem

`auth.type: headers` values are stored in plaintext in `config.yaml`, while other auth types (bearer, hmac, service-account) are encrypted.

Example:
```yaml
services:
  example:
    auth:
      type: headers
      headers:
        X-API-Key: secret-value-in-plaintext  # ← not encrypted
```

## Fix

In `src/cli/config-yaml.ts`:
1. Encrypt each header value when saving (`saveYAMLConfig`)
2. Decrypt each header value when loading (`loadYAMLConfig`)

## Credit

Found by @mkoorn in #14

[Read the thread](https://github.com/rsdouglas/janee/issues/20) · 2026-02-10 · closed · 1 comment

### SSRF vulnerability: validate URL origin before injecting auth

## Problem

An agent can bypass the proxy by passing an absolute URL as the `path` parameter. `new URL("https://evil.com", "https://api.service.com/")` ignores the base URL, but our auth headers are still injected.

## Attack Vector

Prompt-injected agent passes `https://attacker.com/steal` as path → auth token sent to attacker.

## Mitigation

Services with path-based rules (`allow: ['GET /v1/*']`) are protected since `https://evil.com` won't match. Services without rules are vulnerable.

## Fi

[Read the thread](https://github.com/rsdouglas/janee/issues/16) · 2026-02-10 · closed · 0 comments

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