Inside Claude Code's Hidden Autonomous Agent Platform: Reverse Engineering Operon and KAIROS

Factual findings only; no speculation beyond what the binary confirms.

Background

This started as a joke. After Anthropic accidentally leaked the client side code, via an NPM source map, certain sections of the internet exploded with people suddenly becoming experts in code review. Some folks ported the code to various languages, some folks embedded malware in forks of it, and some folks tossed the whole thing into an LLM and presumably prompted “Make me look smart on Linkedin”.

As for me, I had no real interest in snooping around source files. But I did think it would be a hilarious April fools joke to open source a “Claude Code Search” tool which would literally just be a 5 line grep wrapper. I missed April 1 because instead of making a throwaway joke, I accidentally spent a day reverse engineering far more than I expected.

Everything below comes directly from index.js, the minified production binary distributed with Claude Code. No decompilation, no proprietary tools — just grep, pattern matching, and reading minified JavaScript with an LLM.

Methodology

Claude Code ships as an Electron application. Its core logic lives in a single minified JavaScript bundle at:

Claude.app/Contents/Resources/app.asar/build/index.js

The approach throughout was to use grep with context windows to extract meaningful code patterns from what is otherwise an unreadable wall of minified JavaScript. For example:

grep -oE '.{80}kairosActive.{80}' index.js

This gives 80 characters of context on either side of a target string — enough to read surrounding logic without a full deobfuscation pass. Critical both for preserving sanity and not chewing through LLM tokens and context windows needlessly.

Finding 1: KAIROS Is Real and In Production

The initial search confirmed my original suspicion — that no source code was really needed:

grep -o 'kairos[^,;)]*' index.js | head -20

kairosActive:!1
kairosActive:!1

!1 is minified JavaScript for false. KAIROS exists as a feature flag in the production binary. It is currently disabled.

Finding 2: The Session State Object

Pulling wider context around kairosActive revealed it lives inside the global session state object — the object that governs every Claude Code session:

grep -o 'kairosActive[^}]*' index.js | head -5

The relevant excerpt (abbreviated):

kairosActive:!1,
strictToolResultPairing:!1,
sdkAgentProgressSummariesEnabled:!1,
userMsgOptIn:!1,
clientType:"cli",
sessionIngressToken:void 0,
sessionBypassPermissionsMode:!1,
scheduledTasksEnabled:!1,
sessionCronTasks:[],
sessionCreatedTeams:new Set,
sessionTrustAccepted:!1,
sessionPersistenceDisabled:!1,
afkModeHeaderLatched:null,
teleportedSessionInfo:null,
isRemoteMode:!1,
directConnectServerUrl:void 0,
parentSessionId:void 0,
agentColorMap:new Map,
agentColorIndex:0

Several flags in this object stand out:

sessionBypassPermissionsMode — a mode that explicitly bypasses all permission checks
scheduledTasksEnabled + sessionCronTasks[] — cron-style autonomous task scheduling baked into every session
afkModeHeaderLatched — AFK/unattended mode, persistent once set
sessionIngressToken — sessions can be initiated externally via a token
isRemoteMode + directConnectServerUrl — sessions can run remotely
teleportedSessionInfo — sessions can be migrated between environments
parentSessionId — session hierarchy; agents can spawn child agents
agentColorMap — multiple concurrent agents per session, each color-coded

KAIROS sits in this object as a session-level behavior switch alongside scheduledTasksEnabled and sessionBypassPermissionsMode — which means when active, it changes how the agent loop operates at the same level those flags do.

Finding 3: The Permission Mode System

grep -oE '.{60}acceptEdits.{60}' index.js | head -10

var zc=(t=>(t.Default="default",t.AcceptEdits="acceptEdits",
t.Plan="plan",t.Bypass="bypassPermissions",t.Auto="auto",t))(zc||{})

nur=yi(["default","acceptEdits","bypassPermissions","plan","dontAsk","delegate","auto"])

The full permission mode enum (zc) contains seven values:

Mode	Meaning
`default`	Normal — ask for everything
`acceptEdits`	Auto-accept file edits, ask for other actions
`plan`	Plan-only, no execution
`bypassPermissions`	Bypass all permission checks
`dontAsk`	Don’t prompt, but not full bypass
`delegate`	Delegate permission decisions to another agent
`auto`	Fully autonomous

delegate is the most unusual. It does not appear in the set of valid default modes — it can be set at runtime but not persisted as a user default. Its meaning is explained in Finding 8.

Finding 4: The Trust Architecture

Settings Source Hierarchy

The binary contains two distinct settings source hierarchies:

CLI context:

["userSettings","projectSettings","localSettings","session","cliArg"]

Desktop app context:

["userSettings","projectSettings","localSettings","flagSettings","policySettings"]

The Bypass Guard

grep -oE '.{80}only user.{80}' index.js

==0||l===n)&&a.has(f)){$.warn(`[CCD] Ignoring defaultMode "${f}" from ${i[l]} 
— only user-level or managed settings can set auto/bypass as default`);continue}

This guard explicitly prevents projectSettings, localSettings, flagSettings, and cliArg from setting bypassPermissions or auto as a persistent default mode. Only userSettings (index 0) and policySettings (the managed enterprise setting) can do so.

Practical implication: A malicious repository containing a .claude/ settings file cannot escalate itself to bypass mode. The attack surface requires writing to ~/.claude/ (user settings) or enterprise policy configuration.

Per-Project Trust

grep -o '.hasTrustDialogAccepted[^}]*}' index.js | head -10

.hasTrustDialogAccepted)return!0;let s=t;
if(e){const l=(o=r.projects)==null?void 0:o[s];
  return(l==null?void 0:l.hasTrustDialogAccepted)===!0}
for(;s!==null;){
  const l=(c=r.projects)==null?void 0:c[s];
  if(l!=null&&l.hasTrustDialogAccepted)return!0;
  const u=Ae.resolve(s,"..");s=u===s?null:u
}

Trust is checked in cascade:

Check global bypassPermissionsModeAccepted — if set, trust everything immediately
Check the specific project directory path for hasTrustDialogAccepted
Walk up the directory tree checking each parent directory
Stop at filesystem root

Trust granted to a parent directory propagates to all children. Trust granted to /Users/you/projects would cover every project underneath it.

Finding 5: Chrome/Browser Permission System

Chrome (browser agent) permissions are tracked separately from the main session permission mode.

grep -oE '.{60}chromePermissionMode.{60}' index.js | head -5

The chromePermissionMode field accepts exactly three values:

zr.enum(["ask","skip_all_permission_checks","follow_a_plan"])

With an optional chromeAllowedDomains allowlist.

The critical automatic escalation:

(p===zc.Auto||p===zc.Bypass)&&{chromePermissionMode:"skip_all_permission_checks"}

When a session’s main permissionMode is auto or bypassPermissions, Chrome automatically receives skip_all_permission_checks. Browser permissions escalate automatically with session permissions — they are not independently gated.

There is also a classifier for browser actions:

[canUseTool:CIC] computer(wait) → harmless action

An internal classifier (CIC) evaluates browser actions and can auto-allow those it determines to be “harmless” without user confirmation.

Note: this is functionally similar to the remediation steps I listed in the ROTA attack post.

Finding 6: Scheduled Tasks With Independent Permission Modes

grep -oE '.{100}scheduledTask.{100}' index.js | grep -i 'permission\|bypass\|mode'

Scheduled tasks (sessionCronTasks) are not just timers — they are full session configurations with their own permission lifecycle:

Each scheduled task stores its own approvedPermissions[] list, persisted to disk
shouldAutoApprovePermission() auto-approves tools that were previously approved for that task
addApprovedPermission / removeApprovedPermission — permissions accumulate across runs
chromePermissionMode is stored independently per scheduled task
Two separate scheduled task systems exist: CoworkScheduledTasks and CCDScheduledTasks

"Argument "scheduledTaskId" at position 0 to method "removeApprovedPermission" 
in interface "CoworkScheduledTasks" failed to pass validation"

"Argument "scheduledTaskId" at position 0 to method "clearChromePermissions" 
in interface "CoworkScheduledTasks" failed to pass validation"

A scheduled task can run with bypassPermissions mode, accumulate approved tools over time, and operate the browser with skip_all_permission_checks — entirely without user interaction.

Finding 7: teleportToCloud

grep -oE '.{100}teleport.{100}' index.js | head -10

async teleportToCloud(e,r,n){
  const i=await this.sessionManager.getSession(e);
  ...
  r.sshConfig?{ready:!1,...,error:"SSH sessions cannot be teleported to the cloud."}
  :await p0(tI[Jl()])?
    await this.hasDirtyWorkingTree(r.cwd)?
      {ready:!1,needsCommitAndPush:!0,...}
    :{ready:!0,...}
  :{ready:!1,...,needsAuth:!0}

teleportToCloud(sessionId, environmentId) migrates a local Claude Code session to Anthropic’s cloud infrastructure. Pre-conditions:

Session cannot be SSH-based
Working tree must be clean (no uncommitted changes)
User must be authenticated

After teleportation, the session continues running remotely. This explains isRemoteMode and directConnectServerUrl in the session state — post-teleport, the local client connects back to the remote session.

Finding 8: Operon — The Full Autonomous Agent Platform

This is the most significant finding. What appeared to be a feature flag turns out to be a complete embedded autonomous agent platform called Operon.

Infrastructure

grep -oE '.{100}OPERON.{100}' index.js | head -20

Operon maintains its own infrastructure entirely separate from Claude Code’s main session:

~/.operon/operon.db       — SQLite database
~/.operon/workspace/      — Workspace directory  
~/.operon/conda/          — Managed Conda/Python environment

Environment variables:

OPERON_DB_PATH            — Override database location
OPERON_WORKSPACE_BASE     — Override workspace location
OPERON_CONDA_HOME         — Override Conda location
OPERON_ARTIFACTS_DIR      — Override artifacts location
OPERON_SANDBOXED_NETWORK  — Enable network sandboxing ("operon-desktop" vs "operon-cli")
OPERON_ENABLE_LLM_CLASSIFIER — Enable a separate LLM safety classifier on tool calls
OPERON_ENV                — "production" vs other environments
OPERON_DISABLE_AUTO_MODEL_EFFORT — Disable automatic model effort selection
OPERON_CLI_MODE           — Running in CLI vs desktop context

The Tool Registry

grep -oE '.{100}tool_router.{100}' index.js | head -10

Operon exposes a complete tool suite via a tool_router:

Agent & skill discovery:

search_agents — find agents in the registry by capability
search_skills — find available skills
list_frames — list execution frames

Execution & planning:

generate_plan — create a multi-phase execution plan
update_step_status — track plan step completion
submit_output — submit results
ask_user — request human input when needed

Skills & dashboards:

create_skill — create new reusable skills
render_dashboard / patch_dashboard / read_dashboard — live dashboards

Artifacts:

display_artifacts — surface artifacts to the user
read_artifact_lineage — trace artifact provenance

Permission escalation:

request_network_access — request network access
request_host_access — request host filesystem access

Delegation:

delegate_to — synchronous delegation to a named agent
delegate_subtask — async delegation; child runs in background, sends completion notification

Concierge (conversation/project access):

get_conversation_detail
list_artifacts
list_notes
list_folders
search_project

When an agent has access to search_agents, the system injects RULES_DELEGATION into its system prompt. When it has delegate_subtask, it gets RULES_SUBTASK. The rules are injected dynamically based on available tools.

The Agent Registry

grep -oE '.{100}agentExists.{100}' index.js | head -10

class lkn{
  constructor(){
    this._cache=new Map,
    this._builtinToolSchemas=[],
    this._services={}
  }
  agentExists(e){return this._cache.has(e.toUpperCase())}
  getAgent(e){return this._cache.get(e.toUpperCase())??null}

Agents are stored by uppercased name in an in-memory cache. The registry supports:

agentExists(name) — check if an agent is registered
getAgent(name) — retrieve agent configuration
Child agent rehydration — crashed or paused agents can be rehydrated from state
MCP server attachment to specific agents

The `delegate` Permission Mode — Resolved

{error:"delegate_to requires 'agent' and 'task' arguments"}

n={
  agent:{type:"string",enum:e,description:"The agent to delegate to. Use search_agents to find suitable agents."},
  task:{type:"string",description:"The task description for the sub-agent"}
}

delegate permission mode means Claude hands off permission decisions to another agent in the Operon registry. This enables a hierarchical permission model where a supervisor agent can approve or deny actions on behalf of child agents.

Academic Research Integration

The API integrations bundled with Operon reveal its intended use case:

ELSEVIER_INST_TOKEN
SPRINGER_API_KEY
SEMANTIC_SCHOLAR_API_KEY
NCBI_API_KEY
CORE_API_KEY
OPERON_CONTACT_EMAIL
OPERON_EZPROXY_URL / OPERON_EZPROXY_COOKIE

Semantic Scholar, NCBI (PubMed), Elsevier, Springer, CORE, and EZProxy (institutional library proxy) — this is infrastructure for autonomous academic research workflows, not just coding assistance.

The Safety Classifier

OPERON_ENABLE_LLM_CLASSIFIER

const i=process.env.OPERON_ENABLE_LLM_CLASSIFIER??"";
if(!["1","true","yes"].includes(i.toLowerCase()))return["safe",null];

A separate LLM runs as a safety classifier on Operon tool calls. It is disabled by default and must be explicitly enabled via environment variable. When enabled, it evaluates tool calls and returns a safety classification before execution.

Arbitrary JavaScript Restriction

"Arbitrary JavaScript execution is disabled in unsupervised mode."

e?t?t.permissionMode==="auto"||t.permissionMode==="bypassPermissions"?
  {decision:"block",reason:"Arbitrary JavaScript execution is disabled in unsupervised mode."}
  :{decision:"allow",...}

In auto or bypassPermissions mode, arbitrary JavaScript execution is blocked. However, the browser agent continues to run with skip_all_permission_checks in these modes — browser actions are not subject to this restriction.

One More Thing

Buried in the same production bundle, between certificate parsing and VM diagnostics:

"Run the trap, drop the bass"

Someone at Anthropic is having fun.

The Complete Autonomous Pipeline

Putting all findings together, the full unattended autonomous operation stack:

A scheduled task (sessionCronTasks) is configured with a cronExpression, a prompt, and a permissionMode — potentially bypassPermissions or auto
At the scheduled time, a session is created with those permissions. sessionIngressToken enables external initiation.
If the session mode is bypass or auto, the browser agent automatically receives skip_all_permission_checks
The agent operates via Operon’s tool registry — planning, executing, accessing files, the web, academic APIs
The agent can delegate_subtask to other registered agents asynchronously — child agents run in background and send completion notifications
Approved permissions accumulate per task and auto-approve on future runs — the permission surface grows over time
If needed, the session can teleportToCloud to continue running on Anthropic infrastructure
A parent agent with delegate permission mode can approve or deny child agent actions

KAIROS is the product name for this orchestration layer. The infrastructure is already present in the production binary. The feature flag kairosActive:!1 is the only thing standing between the current state and this system being generally available.

Artifacts Referenced

All findings are from:

Claude.app/Contents/Resources/app.asar/build/index.js

Version examined: Claude Code desktop app, build date confirmed April 4, 2026 (grep session timestamp).

Raw grep commands and outputs are preserved in the session transcript.

What This Is Not

This writeup does not claim:

That KAIROS is dangerous or that Anthropic is doing anything improper
That sessionBypassPermissionsMode can be trivially activated by an attacker
That the scheduled task system is exploitable as described
Any knowledge of Anthropic’s internal roadmap beyond what the binary contains

What the binary shows is a coherent, well-architected autonomous agent platform that is implemented, present in production code, and gated behind a single feature flag. The permission architecture includes meaningful guards. The safety classifier exists even if it is opt-in.

The research question this raises is straightforward: when KAIROS ships, what does the threat model look like for accumulated scheduled task permissions + browser bypass + cloud teleportation in combination?

Found something I missed, or want to tell me I got something wrong? liminalstack@proton.me

Anthropic — if any of this is inaccurate, you know where to find me. Same address.

Research conducted via static analysis of a publicly distributed binary. No systems were accessed beyond the researcher’s own machine.

Background#

Methodology#

Finding 1: KAIROS Is Real and In Production#

Finding 2: The Session State Object#

Finding 3: The Permission Mode System#

Finding 4: The Trust Architecture#

Settings Source Hierarchy#

The Bypass Guard#

Per-Project Trust#

Finding 5: Chrome/Browser Permission System#

Finding 6: Scheduled Tasks With Independent Permission Modes#

Finding 7: teleportToCloud#

Finding 8: Operon — The Full Autonomous Agent Platform#

Infrastructure#

The Tool Registry#

The Agent Registry#

The delegate Permission Mode — Resolved#

Academic Research Integration#

The Safety Classifier#

Arbitrary JavaScript Restriction#

One More Thing#

The Complete Autonomous Pipeline#

Artifacts Referenced#

What This Is Not#