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.

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 · 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 · 2026-02-21 · closed · 3 comments

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:

// 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 · 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

Have services configured (verified via janee list CLI which shows all 8 services correctly)
Call list_services via MCP tool
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`

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:

[
  {
    "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

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

Credit

Found by @mkoorn in #14

Read the thread · 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:

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

Fix

In src/cli/config-yaml.ts:

Encrypt each header value when saving (saveYAMLConfig)
Decrypt each header value when loading (loadYAMLConfig)

Credit

Found by @mkoorn in #14

Read the thread · 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 · 2026-02-10 · closed · 0 comments

The remaining reports are on the project's issue tracker.

Reported issues for janee

Most discussed

Security Audit

Security Audit: Janee v0.4.1

Critical: SSRF allows secret exfiltration

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

Janee Exec Architecture Rethink

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

1) What Janee is (and why it matters)

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

MCP list_services returns empty despite configured services

Bug

Reproduction

Expected

2. Install mcp-publisher

Fix

Credit

Encrypt auth.headers values at rest

Problem

Fix

Credit

SSRF vulnerability: validate URL origin before injecting auth

Problem

Attack Vector

Mitigation

Fi

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

2. Install `mcp-publisher`