# agent-signals: all pages

This file holds the Markdown source of each page of https://xsavikx.github.io/agent-signals/, in the order of llms.txt. A line "Source:" starts each page.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/README.md

# agent-signals

Measured signals of AI coding agents, as a language-neutral test corpus.

Tools that watch or drive an agent session read the same signals: the
terminal screen of the agent, the payloads of its hooks, its session files,
and its log lines. Each tool learns the shape of these signals again, and each
tool breaks again when an agent changes its screen. This repository holds the
measured signals once, with the result that each signal must give. Every tool
tests its own reader against the same data.

The first signals are terminal screens of Claude Code, Antigravity CLI (agy)
and Codex CLI in tmux. The corpus also holds the first screen with no login
of each other agent in [the roadmap](docs/roadmap.md). Hook payloads,
session files and log lines follow.

## Who it is for

- Authors of tools that watch or drive an agent session in a terminal. aw
  and tg-bridge are two such tools. Each tool tests its own reader against
  the same screens and facts.
- Agents that do a job in this repository. Each job has a
  [task file](tasks/).
- Operators who must know how an agent behaves on an OS before they
  automate it.

## How to use the corpus

1. Pin a corpus release tag, `corpus-vX.Y.Z`, from the
   [releases on GitHub](https://github.com/xSAVIKx/agent-signals/releases).
2. Copy `corpus/`, `schema/` and `facts/` from that tag into your tree.
3. Run one table test: for each screen, give the `.screen` bytes to your
   reader, and compare the result with `expect` in the `.yaml` file.

The corpus holds no code that your tool runs. Each tool keeps its own reader.

## Run the probe kit on your machine

Run the kit with one command. It downloads the kit of the latest release
(about 30 KB) to a temporary folder, runs the probes, writes one file in the current folder, and deletes
the temporary folder.

| OS | Command |
|---|---|
| macOS, Linux | `curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh \| sh` |
| Windows (PowerShell) | `irm https://xsavikx.github.io/agent-signals/kit.ps1 \| iex` |
| A guided step (macOS, Linux) | `curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh \| sh -s -- --guided permission agent` |

Read the scripts first if you want: [`probes/kit.sh`](probes/kit.sh) and
[`probes/kit.ps1`](probes/kit.ps1). The kit only reads. Read the file that
it writes before you send it.

## What is in the repository

| Path | Content |
|---|---|
| `corpus/<agent>/screens/` | One measured screen per pair of files: `<slug>.screen` and `<slug>.yaml`. |
| `corpus/<agent>/coverage.yaml` | The agent versions that were checked against the corpus. |
| `schema/` | JSON Schema for each `.yaml` file. CI validates every file. |
| `facts/` | Measured facts and the incidents behind them, one file per fact. |
| `protocol/` | Rules for tools that answer an agent, for example the safe way to type into a pane. |
| `probes/` | Read-only scripts for the first discovery of an agent on an OS, and the kit that runs them on a real machine. They read no conversation text. |
| `scenarios/<agent>/<name>.sh` | Scripts that start an agent in a throwaway home folder and a private tmux server, and record its signals. |
| `tools/` | The validator, the sync scripts for the Go and the Python libraries, the scrub for probe output, and the generator of the website. |
| `go/` | The Go library. It holds a committed copy of `corpus/` and `facts/` in `go/data/`. |
| `python/` | The Python library. It holds a committed copy of `corpus/` and `facts/` in `python/src/agent_signals/data/`. |
| `docs/` | The format and the versioning rules, the roadmap, the checks for each OS, and the CI secrets. |
| `AGENTS.md`, `tasks/` | Instructions for agents, and one task file for each job. |

The Go library in `go/` and the Python library in `python/` load the corpus
and give typed fixtures. No library is needed to use the data. Read
[the guide to the Go library](go/README.md) and
[the guide to the Python library](python/README.md).

## A screen

A `.screen` file holds the exact output of `tmux capture-pane -p` (or
`capture-pane -p -e` when the style matters), in UTF-8, with the trailing
newline kept. Do not let an editor change these files. `.editorconfig` and
`.gitattributes` keep the bytes as they are.

The `.yaml` file beside it records the agent, the agent version, the pane
size, how the screen was made, and the expected result. Read
[`docs/format.md`](docs/format.md) for each field.

## Releases

release-please makes each release from the Conventional Commits on `main`.
The repository has three packages, and each package has its own tag and
changelog:

| Package | Tag | Changelog |
|---|---|---|
| The corpus | `corpus-vX.Y.Z` | [`CHANGELOG.md`](CHANGELOG.md) |
| The Go library | `go/vX.Y.Z` | [`go/CHANGELOG.md`](go/CHANGELOG.md) |
| The Python library | `python-vX.Y.Z` | [`python/CHANGELOG.md`](python/CHANGELOG.md) |

The agent versions are data in the corpus, not the version of a package.
Read [`docs/versioning.md`](docs/versioning.md) and the
[releases on GitHub](https://github.com/xSAVIKx/agent-signals/releases).

## Develop

```sh
cd tools && go test ./... && go run ./cmd/validate ..
cd go && go vet ./... && go test ./...
pip install -e "python[test]" && pytest python
```

After a change in `corpus/` or `facts/`, run `tools/sync-go-data.sh`. It also
runs `tools/sync-python-data.sh`. Commit `go/data/` and
`python/src/agent_signals/data/`. The Go tests and the Python tests fail when
a copy is stale.

## The website

The website at <https://xsavikx.github.io/agent-signals/> shows the Markdown
files, the facts and the corpus. The Markdown files stay the source. The
pages workflow builds the site and deploys it from `main`. To build it on
your machine:

```sh
cd tools && go run ./cmd/site -root .. -out ../_site
python3 -m http.server 8000 --bind 127.0.0.1 --directory ../_site
```

### For agents and programs

The website also gives the data in forms that a program can read:

| URL | Content |
|---|---|
| [`llms.txt`](https://xsavikx.github.io/agent-signals/llms.txt) | An index of the site for language models, in the [llms.txt](https://llmstxt.org/) format. |
| [`llms-full.txt`](https://xsavikx.github.io/agent-signals/llms-full.txt) | All Markdown pages in one file. |
| [`corpus.json`](https://xsavikx.github.io/agent-signals/corpus.json) | Each agent, its verified versions, and each screen with its fields and the URLs of its files. |
| [`facts.json`](https://xsavikx.github.io/agent-signals/facts.json) | Each fact with its number, date, agents and URLs. |
| `<page>.md` | The Markdown copy of each page that comes from a Markdown file. |

Each screen also has its `.screen` and `.yaml` files beside its page, for
example `corpus/claude/<slug>.screen`.

## Writing style

All prose uses ASD-STE100 Simplified Technical English. Code, commands, paths
and quoted output stay exact.

## Maintainer

Yurii Serhiichuk maintains this repository. Read more at
[serhiichuk.dev](https://serhiichuk.dev/).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/AGENTS.md

# Instructions for agents

This repository holds measured signals of AI coding agents: terminal
screens, hook payloads, session files and open files. Tools such as aw and
tg-bridge test their readers against it.

Read `CLAUDE.md` first. Its rules apply to every agent, not only to Claude:
no secrets, no host details, no session details, Conventional Commits, and
prose in ASD-STE100 Simplified Technical English.

## Read the data from outside the repository

An agent that only reads the data does not need a clone. Start with
<https://xsavikx.github.io/agent-signals/llms.txt>. It links `corpus.json`,
`facts.json`, and a Markdown copy of each page.

## Jobs

Each job has a task file. Follow the task file step by step.

| Job | Task file |
|---|---|
| Run the probe kit on a real machine and send the file | `tasks/run-the-kit.md` |
| Write a fact from probe or scenario output | `tasks/write-a-fact.md` |
| Add a probe for a new agent or a new OS | `tasks/add-a-probe.md` |
| Add an agent to the roadmap, the probes and CI | `tasks/add-an-agent.md` |

## Where things are

| Path | Content |
|---|---|
| `docs/roadmap.md` | The agents to cover, in order, and the state of each cell of the matrix. |
| `docs/detection.md` | How a tool finds an agent process, links it to its session and reads its state. |
| `docs/os-checks.md` | For each OS: how to see a process, its terminal, its open files and its folder. |
| `docs/ci-secrets.md` | The repository secrets that the model scenarios need. |
| `probes/README.md` | The rules for a probe, and the kit. |
| `scenarios/README.md` | The rules for a scenario. |
| `facts/README.md` | The parts of a fact. |
| `docs/format.md` | The format of a screen. |

## Checks before a commit

1. `cd tools && go test ./... && go run ./cmd/validate ..`
2. `sh tools/sync-go-data.sh`, then `cd go && go test ./...`
   and `pytest python` in a virtual environment with `pip install -e "python[test]"`.
   The sync script also makes the copy for the Python library.
3. `shellcheck --severity=warning` on each changed `.sh` file.
4. `sh tools/test-scrub.sh` when the scrub changed.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/format.md

# The format of a screen

A screen is two files in `corpus/<agent>/screens/`, with the same slug:

- `<slug>.screen`: the exact bytes.
- `<slug>.yaml`: the metadata and the expected result.

`schema/screen.schema.json` is the full definition. This page explains it.

## The `.screen` file

1. It holds the exact output of `tmux capture-pane -p`. When the style
   matters, it holds the output of `capture-pane -p -e`, with SGR escape codes.
2. It is UTF-8, with LF line endings, and the trailing newline is kept.
3. Do not reformat it. An editor that strips trailing white space changes the
   screen without a sign. `.editorconfig` and `.gitattributes` prevent this.

## The `.yaml` file

```yaml
schema: 1
agent: claude                # equals the folder name; see the list below
agent_version: 2.1.309
valid_from: 2.1.251          # optional
superseded_by: null          # optional: the slug that replaces this screen
measured: 2026-10-24
capture: plain               # plain | styled
pane: {cols: 120, rows: 40}   # required for measured; optional when the size is not known
provenance: measured         # measured | measured-edited | derived
edits: []                    # measured-edited: one line for each edit
derived_from: hand-built     # derived: the source slug and what changed, or hand-built
description: >
  What the screen shows, and why it is in the corpus.
expect:
  state: PERMISSION          # IDLE | BUSY | PERMISSION | TRUST | DIALOG_OVER_BOX | NO_BOX | UNKNOWN
  dialog: question           # optional: permission | question | review | trust | none
  question: "Which colour?"  # only where the screen pins it
  options:
    - {n: 1, label: Red, selected: true}   # n is optional: some menus have no numbers
    - {n: 2, label: Blue}
  box_text: null
negative_control_for: null   # optional: the slug this screen must not be confused with
known_false_positive: false  # optional
known_false_positive_reason: null
facts: [7, 15]               # optional: the facts this screen pins
```

## The agents

The `agent` field holds the folder name of the agent. The schemas allow
these names:

| Folder | Agent |
|---|---|
| `claude` | Claude Code |
| `agy` | Antigravity CLI |
| `codex` | Codex CLI |
| `copilot` | GitHub Copilot CLI |
| `gemini` | Gemini CLI |
| `cursor` | Cursor CLI |
| `opencode` | opencode |
| `qwen` | Qwen Code |
| `aider` | Aider |
| `amp` | Amp |
| `goose` | Goose |
| `crush` | Crush |
| `kimi` | Kimi Code CLI |
| `continue` | Continue CLI |
| `droid` | Factory Droid |
| `cline` | Cline CLI |
| `kilo` | Kilo Code CLI |
| `auggie` | Auggie |
| `openhands` | OpenHands CLI |
| `opencode2` | opencode 2 |
| `kiro` | Kiro CLI |
| `junie` | Junie CLI |
| `codebuff` | Codebuff |
| `qoder` | Qoder CLI |
| `codebuddy` | CodeBuddy Code |
| `letta` | Letta Code |
| `neovate` | Neovate Code |
| `everycode` | Every Code |
| `iflow` | iFlow CLI |
| `vibe` | Mistral Vibe |
| `gptme` | gptme |
| `interpreter` | Open Interpreter |
| `grok` | Grok CLI |

A new agent needs its name in `schema/screen.schema.json` and
`schema/coverage.schema.json`. A name that is not in the list is a schema
problem.

## The states

| State | Meaning |
|---|---|
| `IDLE` | A framed input box that waits for a message. A reader must prove this state. It must not give `IDLE` because no other rule matched. |
| `BUSY` | The agent works on a turn. |
| `PERMISSION` | A dialog waits for an answer: a permission, a question, or the review of a question. `dialog` tells them apart. |
| `TRUST` | The folder-trust question. |
| `DIALOG_OVER_BOX` | A dialog draws above a live input box, and the box keeps its frame. |
| `NO_BOX` | The agent has not drawn its input box yet. |
| `UNKNOWN` | A screen that the reader cannot read. A tool must send no key to it. |

## Provenance

| Value | Meaning |
|---|---|
| `measured` | The bytes as tmux captured them. |
| `measured-edited` | Captured, then edited. Each edit has one line in `edits`, for example "path scrubbed to /work/example". |
| `derived` | Hand-built, or made from another screen. `derived_from` names the source and the change. |

## Known false positives

Some expected states are wrong on purpose. A dialog quoted in a reply looks
like a dialog, and a reader that reads it as a dialog sends no key, which is
safe. A rule that reads it as an idle box would also read a real dialog as an
idle box. Such a screen has `known_false_positive: true` and a reason. Do not
"fix" it.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/versioning.md

# Versions

## The repository version

The repository uses semantic versions. release-please makes each release from
the Conventional Commits on `main`. The corpus, the Go library and the
Python library are three packages with their own tags. On GitHub, the newest
corpus release has the mark "Latest". The release workflow sets this mark,
because GitHub otherwise gives it to the package that it released last.

| Change | Version part | Commit type |
|---|---|---|
| A breaking change of a schema or of the layout | major | `feat!:` or a `BREAKING CHANGE:` footer |
| A new screen, a new agent, a new verified agent version, a new fact | minor | `feat:` |
| A correction of a screen, a fact or a document | patch | `fix:` |

Before 1.0.0, a breaking change raises the minor part.

## Agent versions are data

The agent versions are not the version of the repository, for four reasons:

1. One repository covers several agents, and each agent has its own version
   line.
2. The corpus changes when no agent changes, for example for a correction or a
   new field.
3. One screen is often valid across many agent releases.
4. A Go module needs a semantic version tag.

The agent versions are recorded in two places:

1. Each `.yaml` file records the `agent_version` that drew the screen. It can
   also record `valid_from` and `superseded_by`.
2. `corpus/<agent>/coverage.yaml` lists each agent version that was checked
   against the corpus, with the date and the method.

Each release note names the agent versions that the release covers.

## Tags

Each package in the repository has its own version and its own tag.

| Package | Path | Tag |
|---|---|---|
| The corpus (data, schemas, facts, protocol) | `.` | `corpus-v1.2.3` |
| The Go library | `go/` | `go/v1.2.3` |
| The Python library | `python/` | `python-v1.2.3` |

The Go tag has the form `go/vX.Y.Z` because Go finds the version of a module
in a subfolder from a tag with that prefix. release-please makes this tag from
the package settings `component: go`, `tag-separator: /` and
`include-v-in-tag: true`. The default separator is `-`, so the setting is
needed.

## The Go library and the corpus

The Go library embeds a copy of `corpus/` and `facts/` in `go/data/`. Go cannot
embed files from outside the module folder, so the copy is committed.

1. Run `tools/sync-go-data.sh` after each change in `corpus/` or `facts/`.
2. Commit `go/data/` in the same pull request.

The test `TestDataIsInSync` in `go/` fails when the copy is stale, so CI
catches a missing sync.

The root package excludes `go/` and `python/` from its release notes, with
`exclude-paths`. A commit that changes only `go/` or only `python/` does not
make a corpus release. A change of
the corpus also changes `go/data/`. The commit of such a change counts for both
packages, so it makes a release of both. The library version is the version of
the Go code and of the embedded corpus. It is not the version of an agent.

## The Python library and the corpus

The Python package holds a copy of `corpus/` and `facts/` in
`python/src/agent_signals/data/`, so that a wheel needs no other file. The
copy is committed, as for Go.

1. Run `tools/sync-go-data.sh` after each change in `corpus/` or `facts/`. It
   also runs `tools/sync-python-data.sh`.
2. Commit `python/src/agent_signals/data/` in the same pull request.

The test `test_data_is_in_sync` in `python/tests/` fails when the copy is
stale. The tag has the form `python-vX.Y.Z`, from the package settings
`component: python` and `release-type: python`. release-please writes the
version into `python/pyproject.toml`. The data in a release of the Python
library follows the corpus: a change of the corpus makes a release of the
corpus and of the Python library together.

## Schema versions

Each `.yaml` file has a `schema` field. A breaking change of a schema raises
that number and the major part of the corpus version together.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/os-checks.md

# Checks for each OS

How a tool or a probe sees an agent process, its terminal, its open files
and its folder, on each OS. The column "Measured" says where the row was
measured. "Probe" means that a probe uses it and CI runs that probe on a
runner with no agent session.

## Linux

| Question | Command | Measured |
|---|---|---|
| Processes and parents | `ps -axo pid=,ppid=,tty=,args=`; `/proc/<pid>/stat` field 4 | real machine (Debian 13), probe |
| Children | `pgrep -P <pid>` | real machine |
| Working folder | `readlink /proc/<pid>/cwd` | real machine |
| Open files | `readlink /proc/<pid>/fd/*` (no `lsof` needed) | real machine (facts 25, 26, 28) |
| Terminal | `ps -o tty=`; `readlink /proc/<pid>/fd/0` | real machine |
| Environment (own processes) | `/proc/<pid>/environ`, NUL-separated. Print only names from a fixed list: the environment can hold secrets. | real machine |
| ubuntu-slim runner | No `lsof` and no `tmux`. The probes read `/proc`. | CI runner (fact 49) |
| tmux pane of a process | `tmux list-panes -a -F '#{pane_pid} #{pane_id}'`; `TMUX_PANE` in the environment; the `tmux` field of the Claude pid file (fact 23) | real machine |

## macOS

| Question | Command | Measured |
|---|---|---|
| Processes and parents | `ps -axo pid=,ppid=,tty=,args=` | real machine (fact 22), probe |
| Children | `pgrep -P <pid>` | probe |
| Working folder | `lsof -n -P -a -p <pid> -d cwd -Fn` | real machine (aw doctor) |
| Open files | `lsof -n -P -p <pid> -Fn`. 24 agent processes took 0.7 s. | real machine (facts 21, 22; aw doctor) |
| Terminal | `ps -o tty=` | real machine |
| Environment (own processes) | `ps eww -o command= -p <pid>` | probe (no session) |
| Terminal tab of a tty | Terminal: `tell application "Terminal" to get tty of every tab of every window`; iTerm2: `tty of every session of every tab of every window`. The first call can open an Automation dialog. | real machine, Terminal only (fact 22) |
| Bring a tab to the front | Terminal: `set selected of <tab> to true`; iTerm2: `select <tab>`. The kit step `--guided front-tab` tests it. | not measured |
| JetBrains IDE terminal tabs | No known scripting access. `probes/terminals/macos.sh` checks for an AppleScript dictionary. | not measured |
| Ghostty, WezTerm, kitty, Warp | `wezterm cli list`; kitty remote control (`kitten @`). | not measured |
| tmux | Not on the macOS runner images. The scenarios install it with `brew install tmux`. | CI runners (fact 49) |
| `lsof` and `/proc` compared | `lsof -p` lists mapped files (`.node`, `.dylib`) and more; Linux `/proc/<pid>/fd` lists only open descriptors. | CI runners (fact 50) |

## Windows

| Question | Command | Measured |
|---|---|---|
| Processes and parents | `Get-CimInstance Win32_Process` (`ProcessId`, `ParentProcessId`, `CommandLine`) | probe (no session) |
| Working folder | No route without reading the memory of the process. A Claude session shows its folder in its session file. | aw (no route) |
| Open files | psutil `Process.open_files()` lists the log files that an agent holds open (Cursor CLI). Sysinternals `handle.exe -p <pid>` is not part of Windows. | CI runners (fact 54) |
| Terminal driver | A pseudo console (ConPTY) through pywinpty 3.1.2, read with pyte 0.8.2 (`scenarios/conpty.py`). The console host is the `OpenConsole.exe` of the wheel, a child of the driver, not of the agent. | CI runners (fact 51) |
| Home folder of an agent | Most agents read USERPROFILE. Codex CLI ignores USERPROFILE and HOME and writes to the profile of the account, but it uses `CODEX_HOME` when it is set. Open Interpreter, Every Code, Junie CLI and Kiro CLI also write to the profile of the account. Cursor CLI takes the account name from Windows, not from USERNAME. | CI runners (facts 53, 54, 62, 64) |
| Terminal | A console process has no tty. The parent chain shows the terminal program: `WindowsTerminal`, `OpenConsole`, `conhost`, `Code`, a JetBrains IDE. | probe (no session) |
| Environment of another process | No route without extra tools. | not measured |
| psmux (tmux for Windows) | `psmux ls`, `psmux list-panes -a`. Under PowerShell, `send-keys ... C-m` sends a literal `^M`; `Enter` works. | aw (psmux 3.4.0) |
| Codex CLI keys | Tab sends a message. Enter and C-j add a new line. | aw (Codex 0.164.0) |
| Install folder and version | `Get-Command <cmd> -All` lists an npm agent as `<cmd>.ps1`, `<cmd>.cmd` and `<cmd>`. The version is in `node_modules\<package>\package.json` below the npm prefix (`C:\npm\prefix` on the runners). The file version of an `.exe` is not always the agent version. | CI runners (facts 47, 48) |

## State folders of each agent

The same on Linux and macOS, below the home folder. Windows uses
`%USERPROFILE%` for the same names (not measured).

| Agent | Session link | Live signal | Transcript |
|---|---|---|---|
| Claude Code | `~/.claude/sessions/<pid>.json` (`sessionId`, `tmux`) | `status` in the same file: `idle`, `busy`, `waiting` (with `waitingFor`), `shell` for a background shell (facts 23, 31) | `~/.claude/projects/<key>/<session id>.jsonl` |
| Codex CLI | `~/.codex/thread-writer-locks/<session id>.lock`, open in the daemon (fact 26) | `task_complete`, `turn_aborted` records (fact 27); the `Interrupt` and `Stop` hooks (fact 38) | `~/.codex/sessions/YYYY/MM/DD/rollout-<time>-<session id>.jsonl` |
| agy | `~/.gemini/antigravity-cli/presence/<conversation id>.lock`, a flock lock held by the process (facts 28, 44) | hooks `PreInvocation`, `Stop` (fact 28); `status` in `conversation_summaries.db` (fact 45) | `~/.gemini/antigravity-cli/brain/<conversation id>/.system_generated/logs/transcript.jsonl` |
| Cursor CLI | `~/.cursor/chats/<hex>/<chat id>/store.db`, open in the process (fact 21) | not known | `~/.cursor/projects/<key>/agent-transcripts/<chat id>/<chat id>.jsonl` |
| opencode | not known | not known | not known |
| Copilot CLI | `~/.copilot/session-state/<session id>/inuse.<pid>.hold`, open in the process (fact 30) | not known | not known |

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/detection.md

# How a tool detects an agent session

The rules that a tool uses to find an agent process, to link it to its
session, and to read its state. Each rule names its source:

- "fact NNN": measured in this repository.
- "aw": reported by the aw tool (v0.40.0, 2026-10-31) for Claude Code
  2.1.309 to 2.1.314, codex-cli 0.163.0 and 0.164.0, agy 1.4.5 and 1.4.7,
  cursor-agent 2026.10.22-27dcf5f and psmux 3.4.0. This repository did not
  measure a rule that has only this source.
- "aw v0.42.0": reported by aw on 2026-11-01. This repository did not
  measure it.

## What each OS gives

| OS | Process data | Open files | Source |
|---|---|---|---|
| Linux | `/proc`: name, arguments, tty, folder, environment of own processes | `/proc/<pid>/fd`, `/proc/locks` | fact 025, aw |
| macOS | `ps`, `sysctl`: name, arguments, tty; `ps eww` for the environment of own processes | `lsof -n -P -Fn` | facts 021, 069, aw |
| Windows | CIM `Win32_Process`: name, path, command line, parent. A Toolhelp scan gives the name and the path only | Sysinternals `handle.exe` only | facts 051 to 055, 070, aw |

On macOS, the process name of a native Claude Code install can be its
version, for example `2.1.309` (aw).

On macOS, aw reads the folder and the open files of a process with
`proc_pidinfo`, and uses `lsof` when that fails. aw did not measure this
on a real Mac (aw v0.42.0).

A tool reads the version of an agent from its install path or a version
file, and does not run `<agent> --version` (aw v0.42.0). The probes of
this repository run `--version`; the agent kit doctor will not.

## Claude Code

| Step | Rule | Source |
|---|---|---|
| Find | The process name or the program name is `claude` (`claude.exe` on Windows), or the program is `.../claude/versions/<version>`, or the first argument of a node process ends in `claude`. | aw |
| Skip | `claude --chrome-native-host`: no tty, no pid file. | fact 066 |
| Skip | A psmux pane shell whose command line holds a `claude` function. Match the program, not the command line. | fact 070 |
| Link | `~/.claude/sessions/<pid>.json` names the pid. Check that the pid lives and that `procStart` matches, because stale files stay. | facts 023, 066 |
| Link | aw compares `procStart` with the start time of the process on Linux and on Windows (the Windows file-time form matches). On macOS no form matched yet, so aw checks the pid only there. The kit prints the candidate forms on macOS (`probes/claude/unix.sh`); a run on a real Mac is open. | aw v0.42.0 |
| Link | A `.key` file with no `.json` file: the trust question waits, or the process has just started. | fact 023 |
| Link | On Linux, the open task folder `/tmp/claude-<uid>/<key>/<session id>/tasks`. Not on macOS. | facts 025, 066 |
| Link | Two pid files with one session ID (a resume): the live file with the matching start wins, then the later start, then the later status time. | aw |
| State | `status`: `idle`, `busy`, `waiting` (a dialog), `shell`. `waitingFor` names the kind of wait. | facts 023, 031 |
| State | A dialog on the screen wins over the pid file. | aw |
| Pane | `tmux` in the pid file, only when the process runs in tmux. | facts 023, 066 |

## Codex CLI

| Step | Rule | Source |
|---|---|---|
| Find | The program name is `codex` or `codex-*`. Skip `codex-code-mode-host`. | fact 065, aw |
| Skip | The app-server daemon: `app-server` with `--managed-daemon`, or `app-server daemon`. On Windows, a scan with no arguments can skip it by its path: `~\.codex\packages\app-server-daemon\releases\`. | facts 026, 067 |
| Skip | A direct child of a Codex process is a helper. A first argument that is a subcommand (`exec`, `login`, `app-server`) is not a TUI. | aw |
| Link | A TUI with `--no-daemon` holds its rollout file open. In the default mode the daemon holds it. | facts 026, 039 |
| Link | Folder rules: one Codex process in the folder, one rollout with the same `cwd` in `session_meta`, started after the process. Day folders in local time and in UTC. | aw |
| Home | `CODEX_HOME`, else `~/.codex`, on all three systems. | fact 062 |
| State | The last turn record of the rollout file: `task_complete` = idle, `turn_aborted` = idle, `*_call` = busy. The tool call is written before the approval, so the file never shows a permission wait. | facts 027, 036, aw |
| State | On the screen: "esc to interrupt" = busy; `? for shortcuts` = idle. While Codex 0.164.0 streams an answer, the screen can look idle; an open turn in the rollout file then means busy. | fact 020, aw |

## agy

| Step | Rule | Source |
|---|---|---|
| Find | The program name is `agy`, also while the file is renamed to `agy.exe.<hex>.old`. Skip `-p` and `--print`. | fact 071, aw |
| Link | The open files below `~/.gemini/antigravity-cli/`: one ID in `presence/<id>.lock` and `conversations/<id>.db`. | facts 028, 068 |
| Link | On Linux, the holder of the flock lock of `presence/<id>.lock` in `/proc/locks`. A lock file alone proves nothing: the files stay after a process stops. | facts 044, 072 |
| Link | `cache/last_conversations.json` maps a folder to a conversation. The `cli-<time>.log` that started within 10 s of the process names its conversation. | aw |
| State | Hooks: `PreInvocation`, `PostInvocation`, `Stop`. A deny or Esc gives no hook. | facts 028, 041 |
| State | The log line "Surfacing tool confirmation" = a permission wait. The transcript step `WAITING` = permission. | aw |

## Cursor CLI

| Step | Rule | Source |
|---|---|---|
| Find | The program is `cursor-agent`, or `.../cursor-agent/versions/<version>/...`, or `agent` with `index.js` of that folder. | facts 021, 022, aw |
| Skip | An editor agent worker: `anysphere.cursor-agent-worker` in the path, no tty, `VSCODE_PID` set. A `worker-server` child. `-p` and `--print`. | facts 022, 069, aw |
| Link | The open `~/.cursor/chats/<32 hex>/<chat id>/store.db`. The chat ID is the transcript ID. | fact 021 |
| Link | The project folder name: the folder path with `:` removed and each `\` or `/` changed to `-`, for example `D-Projects-shop`. | fact 072, aw |
| State | On the screen: "Run this command?" with `(y)` … `(esc or n)` = permission; `ctrl+c to stop` or a spinner = busy; the placeholder `Plan, search, build anything` or `Add a follow-up` in the box = idle. | aw |
| State | The transcript ends with `{"type": "turn_ended", "status": "success"}` after a turn. | facts 021, 072 |

## psmux on Windows

| Rule | Source |
|---|---|
| Each pane is a `pwsh.exe` child of `tmux.exe`, with a start script of about 4 KB. | fact 070 |
| A tool finds the sessions from the `<session>.port` file names in the psmux data folder. | aw |
| The process names are `psmux.exe`, `pmux.exe` and `tmux.exe`. | facts 070, aw |

## Open questions

These need a measurement on a real machine. The roadmap tracks them.

1. Codex 0.164 and later: the records during a streamed answer, and the
   time to `task_complete`.
2. Codex: the open files after `/new` and `/resume`; the effect of `-C` on
   the process folder; the parent of `codex-linux-sandbox`.
3. Windows: the link type of the Codex install path
   `~\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe`.
4. Cursor: the chat database after `/new-chat` and `--resume`; a
   `turn_ended` record after an interrupt; the parent of `worker-server`;
   the project folder name for spaces, dots and Unicode.
5. Claude: `status` and `waitingFor` during a plan approval and an
   AskUserQuestion dialog; how long a `.key` file is alone; the pid file
   after a crash.
6. agy: a transcript record for a permission wait; the open files with
   `--continue` and `--conversation <id>`; which presence lock belongs to
   the live process on Windows.
7. macOS: the time of `lsof -p` for one process; the terminal names of
   iTerm2, VS Code and the Cursor editor.
8. Windows: whether a process of the same account can read the command
   line and the folder of another process without administrator rights.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/ci-secrets.md

# Secrets for CI

The no-login probes and scenarios need no secret. The model scenarios need
one secret for each agent. Only the operator adds a secret. An agent never
adds one.

## Rules

1. A job that uses a secret runs only on `workflow_dispatch` or on a
   schedule. A pull request cannot start it, and no workflow uses
   `pull_request_target`.
2. GitHub gives no secret to a pull request from a fork.
3. A scenario passes a key to the agent through a file that only the owner
   can read (`scenarios/lib.sh`), not on the command line.
4. One full run of all model scenarios with API keys must cost less than
   2 USD. Each scenario records its cost.

## The secrets

| Secret | Agent | What it enables | Status |
|---|---|---|---|
| `CLAUDE_CODE_OAUTH_TOKEN` or `ANTHROPIC_API_KEY` | Claude Code | the permission scenario on macOS runners | The variable names are not checked in CI. |
| `OPENAI_API_KEY` | Codex CLI | the approval scenarios; the scenario runs `codex login --with-api-key` in the throwaway `HOME` | from `codex login --help` |
| `CURSOR_API_KEY` | Cursor CLI | all Cursor model scenarios, on the Linux server too: it has no Cursor login | from `cursor-agent --help` |
| none known | agy | agy logs in with OAuth in a browser. No key login was found. Its scenarios run only on a machine with a login. | open |
| provider keys | opencode | not checked | open |

## How to add a secret

1. Open the repository settings: Secrets and variables, then Actions.
2. Add the secret with the name in the table.
3. Tell the agent-signals session which names you added.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/docs/roadmap.md

# Roadmap

The agents to cover, in order, and the state of each cell of the matrix.
Updated 2026-10-31, third round.

## Order

1. The agents that aw and tg-bridge read now: Claude Code, Codex CLI,
   Antigravity CLI (agy), Cursor CLI.
2. opencode, Gemini CLI and GitHub Copilot CLI: CLI agents with many users
   that a tool can drive in a terminal.
3. Other terminal agents: Aider, Goose, Amp, Crush, Qwen Code, Kimi Code
   CLI, Kilo Code CLI, Auggie, OpenHands CLI, Kiro CLI, Factory Droid, Cline
   CLI, Continue CLI.
4. More terminal agents (fact 61): Junie CLI, Codebuff, Qoder CLI,
   CodeBuddy Code, Letta Code, Neovate Code, Every Code, iFlow CLI, Mistral
   Vibe, gptme, Open Interpreter, Grok CLI, opencode 2.

## The agents

`not checked` means that nobody in this project ran or read it yet.

| Agent | Command | Install | Login for CI | State folders |
|---|---|---|---|---|
| Claude Code | `claude` | npm `@anthropic-ai/claude-code` (fact 29) | `CLAUDE_CODE_OAUTH_TOKEN` or `ANTHROPIC_API_KEY` (not checked in CI) | `~/.claude/` (`sessions/`, `projects/`), `/tmp/claude-<uid>/` |
| Codex CLI | `codex` | standalone install (seen: the version is in the package path); npm `@openai/codex` (fact 29) | `OPENAI_API_KEY` through `codex login --with-api-key` (from `codex login --help`) | `~/.codex/` (`sessions/`, `thread-writer-locks/`, `packages/`); `$CODEX_HOME` when it is set, on all three systems (fact 62) |
| Antigravity CLI | `agy` | not checked | not known: OAuth in a browser; no key login found | `~/.gemini/antigravity-cli/`, `~/.gemini/config/` |
| Cursor CLI | `cursor-agent`, `agent` | `curl https://cursor.com/install \| bash` (fact 29); Windows `irm 'https://cursor.com/install?win32=true' \| iex` to `%LOCALAPPDATA%\cursor-agent\versions\<version>\` (fact 47) | `CURSOR_API_KEY` (from `cursor-agent --help`) | `~/.cursor/` (`chats/`, `projects/`) |
| opencode | `opencode` | npm `opencode-ai` gives the 1.x line (fact 29) | provider keys through `opencode auth` (not checked) | `~/.local/share/opencode/` |
| Gemini CLI | `gemini` | npm `@google/gemini-cli` (fact 30) | `GEMINI_API_KEY` (not checked) | `~/.gemini/` (`tmp/`, `history/`, `projects.json`), shared with agy |
| GitHub Copilot CLI | `copilot` | npm `@github/copilot` (fact 30) | a GitHub token (not checked) | `~/.copilot/` (`session-state/<id>/inuse.<pid>.hold`); the version in `~/.cache/copilot/pkg/linux-<cpu>/<version>/` or `~/Library/Caches/copilot/pkg/darwin-<cpu>/<version>/` (fact 50) |
| Aider | `aider` | `pipx install aider-chat`; on macOS and ubuntu-26.04 only `uv tool install --python 3.12 aider-chat` works (facts 30, 49) | a provider key (not checked) | `~/.aider/` |
| Goose | `goose` | `curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh \| CONFIGURE=false bash` (fact 46) | not checked | `~/.local/share/goose/`, `~/.local/state/goose/` |
| Amp | `amp` | npm `@ampcode/cli` (fact 46; `@sourcegraph/amp` is renamed to it); no Windows arm64 binary (fact 48) | not checked | `~/.cache/amp/`, `~/.local/share/amp/` |
| Crush | `crush` | npm `@charmland/crush` (fact 46) | not checked | `~/.local/share/crush/` |
| Qwen Code | `qwen` | npm `@qwen-code/qwen-code` (fact 30) | a provider key (not checked) | `~/.qwen/` |
| Kiro CLI | `kiro-cli` | `curl -fsSL https://cli.kiro.dev/install \| bash`; Windows `irm https://cli.kiro.dev/install.ps1 \| iex` (fact 61) | not checked | `~/.kiro/`, `~/.local/share/kiro-cli/data.sqlite3`; Windows: the real `%USERPROFILE%\.kiro` (fact 64) |
| Factory Droid | `droid` | npm `@factory/cli` (fact 46) | not checked | `~/.factory/` |
| Cline CLI | `cline` | npm `cline` (fact 46) | not checked | `~/.cline/data/` (SQLite files in `db/`; a hub daemon with no tty) |
| Continue CLI | `cn` | npm `@continuedev/cli` (fact 46) | not checked | `~/.continue/` |
| Kimi Code CLI | `kimi` | `curl -fsSL https://code.kimi.com/kimi-code/install.sh \| bash`; Windows `irm https://code.kimi.com/kimi-code/install.ps1 \| iex` (facts 46, 47) | not checked | `~/.kimi-code/`; cache `~/.cache/kimi-code/` (Linux), `~/Library/Caches/kimi-code/` (macOS) |
| Kilo Code CLI | `kilo` | npm `@kilocode/cli` (fact 46) | not checked | `~/.local/share/kilo/` (`kilo.db`, `log/`), `~/.config/kilo/` |
| Auggie | `auggie` | npm `@augmentcode/auggie` (fact 46) | not checked | `~/.augment/` |
| OpenHands CLI | `openhands` | `uv tool install --python 3.12 openhands` (fact 46) | not checked | none in the first 20 s |
| Junie CLI | `junie` | `curl -fsSL https://junie.jetbrains.com/install.sh \| bash`; Windows `install.ps1` (fact 61) | not checked | binary in `~/.local/share/junie/`; Windows state in the real `%USERPROFILE%\.junie`; Linux state not checked |
| Codebuff | `codebuff` | npm `codebuff` (fact 61) | not checked | `~/.config/manicode/` |
| Qoder CLI | `qodercli` | npm `@qoder-ai/qodercli` (fact 61) | not checked | `~/.qoder/` |
| CodeBuddy Code | `codebuddy` | npm `@tencent-ai/codebuddy-code` (fact 61) | not checked | `~/.codebuddy/` |
| Letta Code | `letta` | npm `@letta-ai/letta-code` (fact 61) | not checked | `~/.letta/` |
| Neovate Code | `neovate` | npm `@neovate/code` (fact 61) | not checked | none in the first 20 s |
| Every Code | `coder` | npm `@just-every/code` (fact 61) | not checked | `~/.code/`; Windows: the real `%USERPROFILE%\.code` (fact 64) |
| iFlow CLI | `iflow` | npm `@iflow-ai/iflow-cli` (fact 61) | not checked | `~/.iflow/` |
| Mistral Vibe | `vibe` | `uv tool install mistral-vibe` (fact 61) | not checked | `~/.vibe/` |
| gptme | `gptme` | `uv tool install gptme` (fact 61) | not checked | none in the first 20 s |
| Open Interpreter | `interpreter` | `curl -fsSL https://www.openinterpreter.com/install \| sh`; Windows `install.ps1` (fact 61) | not checked | `~/.openinterpreter/` with the Codex file layout (fact 65); Windows: the real `%USERPROFILE%\.openinterpreter` |
| Grok CLI (superagent-ai) | `grok` | `install.sh` of `superagent-ai/grok-cli`; builds for darwin-arm64, linux-x64 and windows-x64 only (fact 61) | not checked | none in the first 20 s |
| opencode 2 | `opencode` | npm `@opencode/cli`, or `curl -fsSL https://opencode.ai/v2/install \| bash`; the opencode 1 installer refuses 2.x (fact 63) | not checked | `~/.local/share/opencode/`, `~/.config/opencode/service.json`; a second process `serve --service` with no tty |

## The matrix

Each cell gives the work that exists, and where it was measured:

- "probe": a probe script exists.
- "CI": the probes workflow runs the probe on a runner with no agent
  installed.
- "real": the probe ran against live sessions on a real machine.

| Agent | Linux | macOS | Windows |
|---|---|---|---|
| Claude Code | probe, CI, real; scenarios `permission-dialog`, `dialog-states`, `plan-and-resume`, `first-run`; facts 23-25, 29, 31-35 | probe, CI; scenario `first-run` (CI); fact 29 | probe, CI; install layout (CI); scenario `first-run-windows` (CI); facts 47, 48, 51, 52 |
| Codex CLI | probe, CI; scenarios `approval`, `two-sessions`, `screens`, `deny`, `interrupt`, `daemon-life`, `first-run`; facts 19, 20, 26, 27, 29, 36-40 | probe, CI; scenario `first-run` (CI); fact 29 | probe, CI; install layout (CI); scenario `first-run-windows` (CI); facts 47, 48, 51, 52, 53 |
| agy | probe, CI; scenarios `turn-signals`, `deny-and-tools`, `continue`; facts 28, 41-45 | probe, CI | probe, CI |
| Cursor CLI | probe, CI; scenario `first-run`; first screen in the corpus; no login on the Linux server; fact 29 | probe, CI, real; scenario `first-run` (CI); facts 21, 22, 29 | probe, CI; install layout (CI); scenario `first-run-windows` (CI); facts 47, 48, 51, 52, 54 |
| opencode | probe, CI; scenario `first-run`; first screen in the corpus; fact 29 | probe, CI; scenario `first-run` (CI); fact 29 | probe, CI; install layout (CI); scenario `first-run-windows` (CI); facts 47, 48, 51, 52 |
| Gemini CLI, Copilot CLI, Qwen Code | scenario `first-run` (CI); first screens in the corpus; facts 30, 56 | scenario `first-run` (CI); fact 30 | install layout (CI); scenario `first-run-windows` (CI); facts 47, 48, 51, 52 |
| Aider | scenario `first-run` (CI); first screens in the corpus; fact 30 | scenario `first-run` (CI, through uv); fact 49 | scenario `first-run-windows` (CI) on x64; the uv install fails on arm64; fact 64 |
| Amp, Goose, Crush, Kimi Code, Continue, Droid, Cline, Kilo Code, Auggie, OpenHands | scenario `first-run` (CI); first screens in the corpus; facts 46, 50 | scenario `first-run` (CI); facts 46, 50, 57 | install layout and scenario `first-run-windows` (CI) for the npm agents and Kimi Code; facts 47, 48, 51, 52 (Amp fails on arm64); Goose and OpenHands: scenario `first-run-windows` (CI) on x64, fail on arm64 (fact 64) |
| Kiro CLI, Junie CLI, Qoder CLI, CodeBuddy Code, Letta Code, Neovate Code, iFlow CLI, Open Interpreter, opencode 2 | scenario `first-run` (CI) on x64 and arm64; first screens in the corpus; facts 61, 63, 65 | scenario `first-run` (CI) on arm64 and x64; fact 61 | scenario `first-run-windows` (CI) on x64 and arm64 (Kiro: the x64 MSI); fact 64 |
| Codebuff, Every Code | scenario `first-run` (CI) on x64 and arm64; first screens in the corpus; Every Code drew an empty pane on 3 of 6 labels; fact 61 | scenario `first-run` (CI); Every Code empty on 2 of 4 labels; fact 61 | scenario `first-run-windows` (CI) on x64; no arm64 build; fact 64 |
| Mistral Vibe, gptme | scenario `first-run` (CI) on x64 and arm64; first screens in the corpus; fact 61 | scenario `first-run` (CI); fact 61 | scenario `first-run-windows` (CI) on x64; the uv install fails on arm64; fact 64 |
| Grok CLI | scenario `first-run` (CI) on x64; no linux-arm64 build; first screen in the corpus; fact 61 | scenario `first-run` (CI) on arm64; no darwin-x64 build; fact 61 | not checked: bash installer only |
| Codex CLI with `CODEX_HOME` | scenario `first-run` as `codex-home` (CI); fact 62 | the same (CI); fact 62 | `first-run-windows` as `codex-home` (CI); fact 62 |

### Agents not added

Checked on 2026-10-31. These agents are not in the CI:

- Warp Oz (`oz`): Linux needs the Warp apt repository, macOS needs a
  Homebrew cask, and Windows has no standalone CLI.
- Plandex: `https://plandex.ai/install.sh` did not answer. The last
  release is cli/v2.2.1 of 2025-07-16.
- Mentat: the repository `AbanteAI/mentat` was not found.
- Trae Agent: it has no release and no npm or PyPI package.
- Roo Code: it has no CLI package. The releases are of the VS Code
  extension only.
- Zed: it has no agent CLI. Zed runs other agents through ACP.
- Charm Mods: the repository is archived. Crush is in the CI.

## Questions from the detection rules

[`docs/detection.md`](detection.md) lists eight open questions from aw
(2026-10-31). Each one needs a measurement on a real machine.

## Requests from tools

The tools asked for these signals on 2026-10-30. The answer gives the fact
or says what is left.

### aw

| # | Request | Answer |
|---|---|---|
| 1 | Cursor, macOS: a file signal for a wait on a permission dialog | Open. The kit step `--guided permission agent` measures it on the Mac. |
| 2 | Codex: does a TUI hold its rollout file open? | Fact 26: no. In the default mode a shared daemon holds it. Fact 39: a `--no-daemon` TUI holds its own file. Fact 40: no table of `state_5.sqlite` links a TUI to its thread. |
| 3 | Cursor: `/new-chat` and `--resume`, old and new `store.db` | Open. Kit steps `new-chat` and `resume`, or a scenario with `CURSOR_API_KEY`. |
| 4 | Cursor: an end record after an interrupt | Open. Kit step `interrupt`. |
| 5 | Claude, Codex, agy: the files that each process holds open | Facts 25, 26, 28 (Linux). Claude: the task folder keeps the first session ID after `/clear` (fact 34). agy: the presence file is a flock lock (fact 44). macOS and Ubuntu: the open files of agy (fact 68), the Claude pid files outside tmux (fact 66). |
| 6 | macOS: bring a tab to the front by its tty | Open. Kit step `front-tab` (Terminal, iTerm2). JetBrains IDEs: `terminals/macos.sh` checks for an AppleScript dictionary. |
| 7 | Cursor: the hash of the chats folder | Open. Needs a chat on a machine with a login. |
| 8 | Cursor, Linux and Windows: the open-file link | Open. Linux: needs a login. Windows: needs `handle.exe`. |
| 9 | Cursor editor agent workers | macOS: fact 69. A worker has no tty and no `TERM`, has `VSCODE_PID`, and holds no chat database open. Linux and Windows: open. |
| 10 | Codex: the sandbox helper parent, and `resume` | Fact 26 (resume). The helper did not run on the Linux server (no namespaces). |
| 11 | agy, macOS: the process shape and the files | Fact 28 (Linux). macOS: the kit. |
| 12 | Windows: Cursor CLI and Codex in psmux | Fact 70: each psmux pane is a `pwsh.exe` with a long start command, and psmux runs as `tmux.exe`. A Cursor CLI or Codex process in a pane: open. |
| 13 | Windows: where the installs keep their version | Fact 47 (x64) and fact 48 (arm64). |
| 14 | An action that opens a permission dialog in the default mode | Claude: a file write with `--permission-mode default` (fact 24). Codex: a file write with `--sandbox read-only` (fact 27). agy: a file write (fact 28). Claude: `ls` and `sleep` open no Bash dialog; `mkdir` opens one (fact 33). |

### tg-bridge

| # | Request | Answer |
|---|---|---|
| 1 | Claude: a structured record of an open dialog | Fact 24: `PermissionRequest` gives the tool and the suggestions, not the labels. Fact 32: for a question, `PreToolUse` and `PermissionRequest` give the question, the header, and the label and description of each option. Fact 33: the digit of "No" depends on the dialog. Fact 31: the pid file names the kind of wait in `waitingFor`. |
| 2 | Claude: a signal that the folder-trust question waits | Fact 23: no `<pid>.json` before the answer. |
| 3 | Claude: an exact link from a pane to its session | Fact 23: `~/.claude/sessions/<pid>.json`. |
| 4 | agy: busy and turn-end signals that do not come from the screen | Fact 28: `PreInvocation`, `PostInvocation`, `Stop`. A deny and an Esc give no hook (fact 41). The `status` in `conversation_summaries.db` shows them (fact 45). |
| 5 | Codex: a signal for an interrupted or denied turn | Fact 27: `turn_aborted` in the rollout file. Fact 36: the digit 3 gives `turn_aborted`, as Esc does. Fact 37: Ctrl+C opens a task dialog. Fact 38: the `Interrupt` hook fires where `Stop` does not. |
| 6 | Cursor: does it load `.claude/settings.json` hooks? A login-state check | Login state: `cursor-agent status` prints `Not logged in` and starts no login (probe section 8). Hooks: open, needs a login. |
| 7 | Codex screens: busy, and the F2 Warnings view | Screens of 0.164.0 in `corpus/codex/screens/`, also the approval dialog, the screen after 3, and the dialog "Task is still running". |
| 8 | agy: `--continue` in an empty folder draws a box that looks idle | Fact 43: it is idle, with the same bytes as a new start. |

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/probes/README.md

# Probes

A probe is a read-only script that collects the first facts about one agent
on one OS: its processes, its parent processes and terminal, the files it
keeps open, and the layout of its session files. A probe needs no release of
a tool, so a new agent or a new OS can start with it.

Paths:

- `probes/<agent>/unix.sh`: Linux and macOS.
- `probes/<agent>/windows.ps1`: Windows.
- `probes/terminals/macos.sh`: the terminal programs and tabs of macOS.
- `probes/lib.sh`, `probes/lib.ps1`: shared functions.
- `probes/run.sh`, `probes/run.ps1`: the kit.
- `probes/kit.sh`, `probes/kit.ps1`: the one-line start of the kit. The website serves them as `kit.sh` and `kit.ps1`.

## Rules for a probe

1. It only reads. It starts no agent, types nothing, and changes no file.
2. It reads no conversation text. It prints record types, field names and
   table layouts, not values. A command line keeps the program, its flags
   and its paths. Other words become `<arg>`. A command line has at most
   240 characters.
3. It prints no names that the user chose. A project folder list shows a
   count and the form of the newest key. A plugin name, a server name and
   a project path in a key or a TOML table name show as `<name>` or
   `<path>`, with a count. An install folder that holds many tools shows
   only the files of the agent.
4. On Windows, it finds the agent process by the process name, the
   executable path, or the script of `node`. It does not use other text of
   a command line, because a shell can hold the agent name in its command
   text.
5. It prints numbered sections, `### N. <title>`. A section with no data
   prints `not found`. A section that needs a missing tool prints
   `not installed: <tool>`.
6. It exits 0 when it ran to the end, also when it found no session.
7. Its output holds real folder and project names. Do not commit the output.
   Send it through `tools/scrub.sh` (or `tools/scrub.ps1`) before it leaves
   the machine, and read it.
8. A fact that uses the output replaces each real path with `/work/example`
   and each account name with `dev`.
9. Put a caution in the script before a step that can open an OS dialog, for
   example an Automation request of macOS.

## The kit

On a real machine, run the kit. It runs each probe whose agent is installed,
runs the scrub, and writes one file in the current folder. No clone is
necessary:

```sh
curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh | sh
curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh | sh -s -- --all
```

```powershell
irm https://xsavikx.github.io/agent-signals/kit.ps1 | iex
& ([scriptblock]::Create((irm https://xsavikx.github.io/agent-signals/kit.ps1))) -All
```

The one-liners download `agent-signals-kit.tar.gz` or `agent-signals-kit.zip`
from the latest release: `probes/` and the scrub, about 30 KB. Each corpus
release has these files and `agent-signals-kit.sha256`. When the latest
release has no kit file, the one-liners download `main`.
`AGENT_SIGNALS_REF` selects a branch or a tag instead.

In a clone:

```sh
sh probes/run.sh            # Linux and macOS
sh probes/run.sh --all      # also the probes of agents that are not installed
```

```powershell
powershell -ExecutionPolicy Bypass -File probes\run.ps1
```

The guided mode measures one event. The kit tells you to do one action in
a session. Then it watches the agent folders for 30 s. It reads no text.
The file has these parts:

- The agent processes before and after the step, with the start time and
  the scrubbed command. A restart during the step shows here.
- The files that changed, and the open files before and after.
- The record types of the new JSONL lines.
- For Claude: the status of each pid file, every 2 s (fact 23).
- For agy: the status, `not_fully_idle` and `step_count` of the newest
  rows of `conversation_summaries.db`, every 2 s (fact 45). This needs
  `python3`.

The step stops when no session of the agent runs. It does not count the
kit itself, also when the one-line start puts the agent name on the
command line of the kit. `tools/test-guided-step.sh` checks this with a
stub agent.

```sh
sh probes/run.sh --guided permission agent    # a permission dialog waits
sh probes/run.sh --guided new-chat cursor     # /new-chat
sh probes/run.sh --guided resume cursor       # --resume
sh probes/run.sh --guided interrupt codex     # Esc while the agent works
sh probes/run.sh --guided front-tab           # macOS: select a tab by its tty
```

`front-tab` changes the selected tab, so it asks before it runs.

## How a probe becomes a fact

1. The operator runs the kit on the real machine and sends the file.
2. A tool author reads the output and writes one fact for each finding in
   `facts/`, with the date, the agent version, where it was measured, and
   what was not measured.
3. When a tool can collect the same data, for example `aw doctor`, the tool
   takes it over. The probe stays for the first discovery of the next
   version.

## Probes

| Probe | Agent | OS | Facts |
|---|---|---|---|
| `claude/unix.sh` | Claude Code | Linux, macOS | 23, 25 |
| `codex/unix.sh` | Codex CLI | Linux, macOS | 26 |
| `agy/unix.sh` | Antigravity CLI | Linux, macOS | 28 |
| `cursor/unix.sh` | Cursor CLI (`agent`, `cursor-agent`) | Linux, macOS | 21, 22 |
| `opencode/unix.sh` | opencode | Linux, macOS | |
| `copilot/unix.sh` | GitHub Copilot CLI | Linux, macOS | 30 |
| `gemini/unix.sh` | Gemini CLI | Linux, macOS | 30 |
| `terminals/macos.sh` | terminal programs | macOS | 22 |
| `claude/windows.ps1` | Claude Code | Windows | |
| `codex/windows.ps1` | Codex CLI | Windows | |
| `agy/windows.ps1` | Antigravity CLI | Windows | |
| `cursor/windows.ps1` | Cursor CLI (`agent`, `cursor-agent`) | Windows | |
| `opencode/windows.ps1` | opencode | Windows | |

CI (`.github/workflows/probes.yml`) runs each probe and the kit with no
agent installed, on ubuntu-22.04, ubuntu-24.04, ubuntu-26.04, the three
`-arm` labels, ubuntu-slim, macos-15, macos-26, macos-15-intel,
macos-26-intel, windows-2022, windows-2025 and windows-11-arm. The check is
that each probe runs to the end and prints all its sections. A failure on
ubuntu-slim does not fail the workflow.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/scenarios/README.md

# Scenarios

A scenario starts an agent, sends scripted keys, and records the signals:
screens, hook payloads, session files, and open files. A probe only reads
sessions that already run (see `probes/README.md`). A scenario makes its
own session.

Path: `scenarios/<agent>/<name>.sh`. Shared functions: `scenarios/lib.sh`.

## Rules for a scenario

1. It runs the agent in a throwaway `HOME` and a private tmux server
   (`tmux -L`). The cleanup trap kills the server and deletes the
   throwaway folder.
2. It copies a login into the throwaway `HOME` only with `copy_login`.
   `copy_login` refuses a login that is near its expiry, because a token
   refresh in the copy could make the original login fail.
3. An API key goes to the agent through a file that only the owner can
   read, never through the command line.
4. Its prompts are neutral text that can be public. A prompt that must
   open a permission dialog asks for a file write in the throwaway folder.
5. Its output goes to `out/`, which git ignores. Do not commit it. Send it
   through the scrub before it goes into a CI log or an artifact.
6. The header of the script says what it needs, what it costs, and which
   questions it answers.

## Scenarios

CI (`.github/workflows/scenarios.yml`) runs `first-run.sh` for each agent
on 10 Linux and macOS labels, in four agent groups (a to d), and
`windows-installs.ps1` and `first-run-windows.ps1` on windows-2022,
windows-2025 and windows-11-arm, in four agent groups, by hand and once a
week. It needs no secret. A start by hand can select one job with the
input `job`.

| Scenario | Agent | Facts |
|---|---|---|
| `first-run.sh <agent> [command]` | each agent, no login | 29, 30, 46, 49, 50, 56, 57, 61, 62, 63, 65 |
| `windows-installs.ps1 NAME=CMD[=NPMPKG] ...` | each agent on Windows, not started | 47, 48 |
| `first-run-windows.py <agent> [command]` (through `first-run-windows.ps1`) | each agent on Windows, no login | 51, 52, 53, 54, 55, 62, 64 |
| `claude/permission-dialog.sh` | Claude Code | 23, 24 |
| `claude/dialog-states.sh` | Claude Code | 31, 32, 33, 34 |
| `claude/plan-and-resume.sh` | Claude Code | 31, 32, 35 |
| `codex/approval.sh` | Codex CLI | 26, 27 |
| `codex/two-sessions.sh` | Codex CLI | 26 |
| `codex/screens.sh` | Codex CLI | 20 (screens of 0.164.0) |
| `codex/deny.sh` | Codex CLI | 36, 38 |
| `codex/interrupt.sh` | Codex CLI | 37, 38 |
| `codex/daemon-life.sh` | Codex CLI | 39, 40 |
| `agy/turn-signals.sh` | Antigravity CLI | 28; superseded in part by 42 |
| `agy/deny-and-tools.sh` | Antigravity CLI | 41, 42, 44, 45 |
| `agy/continue.sh` | Antigravity CLI | 43, 44 |

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/protocol/README.md

# Protocols

Rules for tools that act on an agent session, for example a tool that types
an answer into a pane. A protocol is prose and data, not code. Each rule names
the facts that it comes from.

## Files

- [`answer.md`](answer.md): the safe way to answer a dialog or type a message into an agent pane.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/protocol/answer.md

# The safe answer protocol

These rules are for a tool that sends keys into the tmux pane of an agent: an
answer to a dialog, or a message for the input box. Each rule names the facts
in `facts/` that it comes from. The tg-bridge project measured these facts.

A wrong key in a live pane can end a session, confirm an option that nobody
chose, or lose a message. When a rule cannot be met, send no key, and report
the screen to the operator.

## The rules

1. **Run tmux with an argv list. Never build a shell string.** No shell then
   parses an argument, so a message that holds metacharacters stays data.
   Facts: 11.
2. **Refuse an argument that is a lone `;`, and a name that ends with `;`.**
   tmux reads such an argument as a command separator, also in argv. Do not
   depend on this refusal alone for a value that you did not validate.
   Facts: 11.
3. **Assert a result, not an exit status.** tmux prints an access refusal and
   exits 0. Facts: 12.
4. **Read the state of the pane again immediately before each key.** The
   screen changes between two reads: a wizard shows its next question, a
   suggestion appears, or another actor uses the pane. Facts: 3, 5, 16.
5. **Send no key to a screen that gives UNKNOWN.** A reader gives IDLE only
   when it proves a framed input box. A modal, an overlay, a setup screen and
   a screen with no known shape give UNKNOWN. Facts: 1, 16, 17, 18.
6. **Send no message to a dialog above a live box.** The dialog takes the
   Enter, and the text stays in the box. A known false positive (a quoted
   dialog) also gives this state, and the refusal is safe. Facts: 2.
7. **Bind each decision to the dialog that it answers.** A decision carries
   the option number and a fingerprint of the dialog: a short hash of the
   question and the numbered options that the operator saw. Before the key,
   read the dialog again and make the fingerprint again. When the two differ,
   send no key, because the same number can mean another option in another
   dialog. Facts: 3, 4.
8. **Answer a numbered dialog with its digit.** A digit activates its option at
   once, with no Enter, and it does not depend on where the mark is. After the
   key, read the screen again: the next question of a wizard fires no hook.
   For a dialog above a live box, no measurement proves that a digit
   activates an option, so treat that answer as not proved. Facts: 2, 3, 4.
9. **Prove which option of the folder-trust menu is selected before you send
   Enter.** Send Enter on the accept option only. Move the mark with Down, with
   a limit on the number of moves, and prove each move on a new screen. The
   start option differs between agents and between versions. Facts: 10.
10. **Type a message in this order:**
    1. Wait until a framed input box is visible. Keys sent before it are lost.
    2. Send `C-u` to clear the box. Prove that the box is empty. Read the box
       with `capture-pane -e`, and remove faint text, because a suggestion
       stays after `C-u`. Refuse a box that does not clear.
    3. Wait a clear gap before the text, for the first message of a new
       process.
    4. Type the text with `send-keys -l`.
    5. Poll until the text is visible in the box. A long text can show as a
       paste marker. Accept the marker only when the box held no marker
       after the clear.
    6. Send Enter.
    7. Prove that the framed box no longer holds the text. Give the agent a
       budget that grows with the length of the text.

    Facts: 2, 5, 7, 8, 9, 13, 14.
11. **Run each send with a deadline, and give each read its own budget.** A
    pane redraws after a key, not with it, so each read polls until the screen
    agrees. One read must not use the whole deadline. When the deadline ends,
    clear the box only when it holds your own text and nothing more. Then
    report that nothing was sent. Facts: 7, 8.
12. **Do not read a reply from the pane.** `capture-pane` gives the visible
    screen only. Take the reply from a hook or a session file. Facts: 6.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/tasks/add-a-probe.md

# Task: add a probe for a new agent or a new OS

## Goal

A read-only script that prints the processes, terminals, open files and
session folders of one agent on Linux and macOS (`unix.sh`) or Windows
(`windows.ps1`).

## Inputs

- The agent command and its state folders. Find the folders with
  `ls -a ~` before and after a first start of the agent in a throwaway
  `HOME`.

## Steps

1. Copy the probe of a similar agent, for example `probes/agy/unix.sh`.
2. Change the header line, the process pattern, and the state folders.
3. Keep the rules of `probes/README.md`: read only, no conversation text,
   numbered sections, `not found` for an empty section, exit 0.
4. Use only the helpers of `probes/lib.sh` or `probes/lib.ps1` to read
   processes and files. A helper hides values that can be private.
5. Run the probe on a machine with no session of the agent. Each section
   must print `not found` or data.
6. Run `sh tools/check-probe-output.sh <probe> <output>`.
7. Add the agent to `pattern_of`, `state_dirs` and `agents` in
   `probes/run.sh` (and the map in `probes/run.ps1`).
8. Add a row to the table in `probes/README.md`.
9. Commit with `feat: add the <agent> probe for <os>`. Open a pull request.
   The probes workflow runs it on all runner types.

## Done when

The probes workflow passes on Linux, macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/tasks/add-an-agent.md

# Task: add an agent

## Goal

The agent has a row in `docs/roadmap.md`, a probe for each OS, and a
first-run scenario.

## Steps

1. Add a row to `docs/roadmap.md`: the command, the install method, the
   login method for CI, and the state folders. Write `not checked` for each
   value that you did not see yourself.
2. Install the agent in a throwaway `HOME` on a machine where you may
   install software. Start it once, with no login. Record the files that
   it makes.
3. Add the probes. Follow `tasks/add-a-probe.md`.
4. Add `corpus/<agent>/` only when you have a measured screen. Follow
   `docs/format.md`.
5. Add a scenario in `scenarios/<agent>/` when a signal needs an action.
   Follow `scenarios/README.md`. A scenario that needs a model turn says
   so in its header, with its cost.
6. Update the matrix in `docs/roadmap.md`.
7. Commit each part as its own pull request.

## Done when

The roadmap row has no `not checked` value for the command and the state
folders, and the probes workflow passes.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/tasks/run-the-kit.md

# Task: run the probe kit on a real machine

## Goal

One scrubbed file that shows how the agents on this machine run: their
processes, terminals, open files and session folders.

## Inputs

- curl or wget (Linux, macOS), or PowerShell (Windows). A clone of this
  repository is not necessary.
- Agent sessions that run now, if possible. A probe finds more when
  sessions run.

## Steps

1. Open a terminal in a folder where the kit can write its file.
2. Run the kit:
   - Linux or macOS: `curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh | sh`
   - Windows, in PowerShell: `irm https://xsavikx.github.io/agent-signals/kit.ps1 | iex`
   - In a clone: `sh probes/run.sh`, or
     `powershell -ExecutionPolicy Bypass -File probes\run.ps1`
3. On macOS the kit asks if it can run the terminal probe. Caution: that
   probe can open a macOS dialog that asks for Automation access to
   Terminal or iTerm2. You can say no.
4. Open the file that the kit names, `agent-signals-probe-<os>-<time>.txt`.
5. Read the whole file. Look for names of projects, people, companies and
   hosts that the scrub did not change. Replace each one with `example`.
6. Send the file to the session that asked for it.

## Guided steps (optional, Linux and macOS)

A guided step measures one event. Run one step at a time:

1. `curl -fsSL https://xsavikx.github.io/agent-signals/kit.sh | sh -s -- --guided permission <agent>`,
   or `sh probes/run.sh --guided permission <agent>` in a clone.
2. Do the action that the kit prints, for example "ask for a file write and
   wait for the permission dialog".
3. Push Enter. Do not touch the session for 30 s.
4. Read and send the file, as in steps 4 to 6 above.

Steps: `permission`, `new-chat`, `resume`, `interrupt`, `front-tab`.
Agents: `claude`, `codex`, `agy`, `cursor` (the Cursor CLI, also `agent` or `cursor-agent`), `opencode`,
`copilot`, `gemini`. With no agent, the step watches all of them. The step
stops when no session of the agent runs.
Caution: `front-tab` changes the selected terminal tab. It asks before it
runs.

## Done when

The session that asked has the file, and you read the file before you sent
it.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/tasks/write-a-fact.md

# Task: write a fact from probe or scenario output

## Goal

One file in `facts/` that states one measured finding, how it was
measured, and what was not measured.

## Inputs

- Probe output (from the kit) or scenario output (from `out/`).
- The agent version and the OS of the run.

## Steps

1. Find the next free number: the highest `facts/NNN-*.md` plus one.
2. Make `facts/NNN-<short-slug>.md` with these headings, as in
   `facts/README.md`: `Measured`, `What was measured`, `Mechanism`,
   `Incident`, `Screens`, `Not measured`.
3. Under `Measured`, give the date, the agent version, the OS and CPU
   type, how it was measured (the probe or the scenario), and one line
   `Measured on: real machine`, `Measured on: CI runner <image>`, or
   `Measured on: emulation <image>`.
4. Under `What was measured`, write only what the output shows. Use
   `/work/example` for each path and `dev` for each account name. Do not
   copy conversation text.
5. Under `Not measured`, list what a reader could expect but the run did
   not show: other OSes, other versions, other keys.
6. Add the fact number to the `Facts` column of the probe or scenario in
   its README.
7. Run `sh tools/sync-go-data.sh`, then the checks in `AGENTS.md`.
8. Commit with `feat: add fact NNN ...`. Open a pull request.

## Done when

CI passes, and each sentence of the fact comes from the output.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/README.md

# Facts

One file per measured fact: `NNN-<slug>.md`, numbered in order. A screen
names the facts that it pins in its `facts` field.

Each fact gives:

1. The date and the agent version that were measured, and one line that
   says where: `Measured on: real machine`, `Measured on: CI runner <image>`,
   or `Measured on: emulation <image>`.
2. What was measured, and how.
3. The mechanism: why the agent behaves this way, when it is known.
4. The incident that the fact caused, when there was one.
5. The screens that pin the fact.
6. What was not measured.

A fact that a later version changes stays in the file. Add the new
measurement below it, with its date and version, and mark the old one as
superseded.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/001-idle-must-be-proved-by-a-frame.md

# 001. An idle input box must be proved by its frame

## Measured

2026-08-18. The Claude Code version was not recorded. tg-bridge documents
2.1.226 on 2026-08-10 and 2.1.238 on 2026-08-20, so the version is in that
range.

## What was measured

The Rewind dialog of Claude Code draws the input mark `❯` as its list cursor,
at the start of a line. No rule of `─` is above or below that cursor. The
folder-trust menu and the permission dialog also draw an unframed `❯`. A real
input box has one rule immediately above the mark and one more rule below it.

## Mechanism

A reader that finds the input box by the last line-starting mark finds the
cursor of the modal. The text after that mark holds no known marker. A reader
that gives IDLE when no marker matches therefore gives IDLE for a live modal.

The safe order of the tests is:

1. Test the known markers: the trust question, the permission footer, the busy
   footer.
2. Test for a numbered list under an unframed cursor (fact 3).
3. Test for a dialog above a framed box (fact 2).
4. Test the frame last. A screen with no frame gives UNKNOWN. A screen with a
   frame gives IDLE.

A frame test before step 1 makes the trust menu and the permission dialog give
UNKNOWN, because both draw an unframed mark.

## Incident

A tool read the Rewind dialog as IDLE. It typed a message into the live dialog
for its whole send timeout, and it then reported that the text did not reach
the pane.

## Screens

`claude/idle`, `claude/busy`, `claude/rewind`, `claude/typed-list`,
`claude/permission`, `claude/trust`.

## Not measured

The size of the pane. The exact version. Modals other than Rewind and the
Remote Control modal (fact 16).

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/002-a-dialog-can-draw-above-a-live-box.md

# 002. A dialog can draw above a live input box

## Measured

2026-09-28, Claude Code 2.1.283, on two live sessions.

## What was measured

The auto mode environment dialog draws a numbered list and the footer "Enter
to confirm · Esc to cancel" between two rules ABOVE the input box. The box
below it keeps its frame and the text that the operator did not send. The last
line-starting mark is the mark of the box, so each marker of the dialog is
outside the input region, and the frame test gives IDLE.

## Mechanism

A reader needs two conditions together to find this dialog: a numbered list
under a cursor mark in the block between the rules above the box, and the
footer text in that block. One condition alone is not sufficient. A reply
often holds a numbered list above the box, and a reply can quote the footer as
prose. The corpus holds one negative control for each condition.

A reply that quotes a whole dialog holds both conditions. No text on the
screen tells the quote apart from a real dialog. A reader that reads the quote
as a dialog sends no key, which is safe. This is a known false positive.

The defence that also covers the next new shape is a proof of submission:
after the Enter, prove that the framed box no longer holds the text. The proof
applies to a framed box only. A pane with no frame can keep the echo of the
text below the mark after a submission.

## Incident

A tool typed a message into each of the two sessions, proved that the text was
visible, and sent an Enter. The dialog took the Enter. The text stayed in the
box, and the Enter confirmed the selected option. In one session option 1 was
confirmed, and a setup command ran. Nothing measured who pressed that Enter.

## Screens

`claude/dialog-over-box`, `claude/overlay-without-footer`,
`claude/overlay-plain-list`, `claude/overlay-footer-without-options`,
`claude/quoted-dialog`.

## Not measured

Whether a digit activates an option of this dialog. Its footer says "Enter to
confirm", and no test proves a digit. The size of the pane. Whether other
dialogs draw above the box. agy 1.4.5 draws no dialog above the box (fact 18).

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/003-a-question-wizard-fires-one-notification.md

# 003. A question wizard fires one Notification, and its review screen has no footer

## Measured

2026-09-08, Claude Code 2.1.263, on a live session.

## What was measured

An AskUserQuestion wizard of two questions fires the `Notification` hook for
its first question only. A digit activates an option at once, and the wizard
then shows its next question. No hook fires for that question. The review
screen at the end draws "1. Submit answers" and "2. Cancel" under the cursor,
with no footer, so the "Esc to cancel" marker is absent.

## Mechanism

A tool that waits for a hook does not learn about the next question. A tool
must read the screen again after each key that it sends to a dialog. A reader
must read a numbered list under an unframed cursor as a dialog. The frame
keeps text that is typed into a real box out of this rule. The Rewind list and
the Remote Control modal have no numbers, so the rule does not reach them.

## Incident

A tap answered the first question of a wizard. The session then waited thirty
minutes on the second question, and nobody was told about it. Until that day
the review screen read as UNKNOWN, so the tool refused the one key that ends
the wizard.

## Screens

`claude/ask`, `claude/review`, `claude/typed-list`.

## Not measured

A wizard of more than two questions. The size of the pane.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/004-a-digit-answers-a-numbered-dialog.md

# 004. A digit answers a numbered dialog at once

## Measured

Claude Code permission dialog: tg-bridge finding F8. The files read for this
port do not give its date. The gated contract lane of tg-bridge checks it
again for each new version. Claude Code wizard: 2026-09-08, 2.1.263. agy
command permission: 2026-10-23, agy 1.4.5.

## What was measured

A digit key sent to a numbered permission dialog activates that option with no
Enter. The same is true for each question of an AskUserQuestion wizard and for
its review screen. In agy, a digit answers the command permission dialog with
no Enter.

## Mechanism

A digit is the safest answer to a numbered dialog, because it names one
option. It does not depend on where the mark is. A digit that goes to an idle
box becomes text in the box. A tool must therefore read the state again just
before it sends the digit.

## Incident

None recorded.

## Screens

`claude/permission`, `claude/ask`, `claude/review`, `agy/permission`,
`agy/file-permission`, `agy/question`.

## Not measured

The dialog above a live box (fact 2). The agy file-write dialog and the agy
question tool: their state was measured, but this port found no record that a
digit answers them.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/005-a-suggestion-is-faint.md

# 005. The suggestion in the input box is faint

## Measured

The suggestion: tg-bridge finding F12. The screen module of tg-bridge dates
its first screens to Claude Code 2.1.226 on 2026-08-10. The faint style:
2026-10-24, Claude Code 2.1.309, with `capture-pane -e`. agy: 2026-10-24, agy
1.4.5.

## What was measured

After a turn, the input box of Claude Code can show a probable next
instruction that nobody typed. An Enter does not submit it. `capture-pane -p`
draws it in the same way as typed text. With `capture-pane -p -e`, the
suggestion `run git status` and the placeholder `Try "how does <filepath>
work?"` of a new box have SGR 2 (faint). The same text, typed, has no SGR 2. A
`C-u` does not remove the suggestion.

## Mechanism

Text in the input region of a plain capture is not proof that the box holds
it. A tool that must know the text of the box reads the box with `-e` and
removes each faint character. agy 1.4.5 drew no suggestion and no placeholder
in the turns that were measured. agy draws its model name faint in the footer,
outside the box.

## Incident

A message that was equal to the suggestion read as a box that does not clear.
The tool typed nothing, and it failed after its whole timeout.

## Screens

`claude/suggestion`, `claude/styled-suggestion`, `claude/styled-typed-same`,
`claude/styled-placeholder`.

## Not measured

Other terminal types and other colour themes. Whether each suggestion is faint
in each version.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/006-the-alternate-screen-has-no-scrollback.md

# 006. A pane in the alternate screen has no scrollback

## Measured

On a live Claude Code session. The fact records no date and no version. The
gated contract lane of tg-bridge checks it again for each new version.

## What was measured

Claude Code switches to the alternate screen. tmux keeps that screen apart
from the history. The live session gave `alternate_on=1` and
`history_size=0/2000` after two hours. `capture-pane -S -200` returned about
24 lines.

## Mechanism

`capture-pane` returns the visible screen and nothing more. Text that scrolled
away is absent, not short. A tool that needs the reply of a turn must take it
from a hook or a session file, not from the pane.

## Incident

The first capture tests captured a plain shell. A plain shell uses the normal
screen, which has scrollback, so the tests passed one step away from the
defect.

## Screens

None.

## Not measured

agy. The fact names Claude Code only.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/007-the-input-box-draws-late.md

# 007. The input box draws late, and early keys are lost

## Measured

Claude Code, from the first deployment of tg-bridge in August 2026. The fact
records no exact date and no version.

## What was measured

The Claude Code TUI takes about 15 seconds to draw its input box on a warm
machine, and longer on a cold one. Keys that arrive before the box go nowhere.
`C-u` empties one line only, so a message that wrapped keeps the rest.

## Mechanism

A tool must prove that its text reached the box before it sends Enter: clear
the box, type, read the screen, and repeat until the text is visible. A box
that does not clear must be refused, not typed over.

## Incident

None recorded apart from facts 8 and 9.

## Screens

None.

## Not measured

The time for agy. The distribution of the time on a loaded machine.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/008-a-pane-redraws-after-a-key.md

# 008. A pane redraws after a key, not with it

## Measured

2026-08-13. The Claude Code version was not recorded.

## What was measured

The screen showed a `C-u` after 0.12 s and typed text after 0.13 s.

## Mechanism

Each read of the screen after a key must poll until the screen agrees. Each
poll needs a budget of its own as well as the deadline of the whole send. A
pane that starts cold draws no input line, so one attempt must not use the
whole send.

A unit test that gives a fixed list of screens models no delay and proves
nothing. Keep the state of one box in the fake, and make each key take effect
one capture later.

## Incident

A read with no wait made every message fail while the text sat in the box. The
tool typed again on each attempt, and the box held up to thirty copies of one
message.

## Screens

None.

## Not measured

The delay for agy. The delay on a loaded machine.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/009-a-fast-clear-leaves-an-invisible-character.md

# 009. A clear followed fast by text leaves an invisible character

## Measured

2026-10-19, Claude Code 2.1.302. Then 2026-10-24, Claude Code 2.1.309 and agy
1.4.5, with a load average of 15 to 47.

## What was measured

In the first seconds after the box draws, a `C-u` that text follows 20 ms
later stays in the box as an invisible character. The Enter then shows
"Removed 1 invisible character · review and press Enter to send", and it
submits nothing. An empty box shows the clear at once. With a wait of 3 s
after the box, the same keys submitted.

On 2026-10-24, with no gap after the clear, the first message of a new Claude
Code process showed the invisible character in 28 of 125 sends, up to 15.9 s
after the box first drew. A later message showed it in no send. agy showed it
in no send.

## Mechanism

A visible clear is not a finished clear. A tool waits a clear gap between the
`C-u` and the text until it has proved one submission in that process and some
time has passed since that proof. A new process needs the gap again.

## Incident

A message in the first seconds after a new session, a restart or a resume
failed in this way.

## Screens

None.

## Not measured

The shortest safe gap. The cause inside Claude Code.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/010-the-trust-menu-reversed.md

# 010. The folder-trust menu of Claude Code reversed in 2.1.251

## Measured

2026-09-01, Claude Code 2.1.251. agy: 2026-10-23, agy 1.4.5.

## What was measured

Before 2.1.251, the options were numbered, and the mark started on "1. Yes, I
trust this folder". From 2.1.251, the options have no numbers, the order is
reversed, and the mark starts on "No, exit". A bare Enter ends the session.
One Down moves the mark to "Yes, I trust this folder".

The menu of agy 1.4.5 lists "Yes, I trust this folder" first, and the mark
starts on it.

## Mechanism

A tool must prove which option is selected before it sends Enter, and send
Enter on the accept option only. It sends Down while the mark is elsewhere,
with a limit on the number of moves, and it proves each move on a new screen.

## Incident

A tool sent a bare Enter to the menu, and the session ended. Eleven patch
versions passed with no contract run. The running deployment reported nothing,
because the menu shows only in a folder that Claude Code never opened. The
gated contract lane found it.

## Screens

`claude/trust`, `claude/trust-accept-selected`, `agy/trust`.

## Not measured

The agy menu with the mark on "No, exit": agy started on the accept option.
The exact Claude Code version that made the change.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/011-tmux-reads-a-lone-semicolon-as-a-separator.md

# 011. tmux reads a lone ";" argument as a command separator

## Measured

tmux 3.5a, the version that the tg-bridge deployment uses. The fact records no
date.

## What was measured

A tool that runs tmux with an argv list uses no shell. The tmux parser still
reads an argument that is a single `;` as a separator between two tmux
commands. tmux also reads an argument that ends with `;` as the end of a
command.

## Mechanism

An argv list keeps shell metacharacters as data, but it does not protect
against the parser of tmux. A tool refuses an argument that is a lone `;`, and
a name that ends with `;`. A caller must not depend on that refusal alone when
it builds argv from a value that it did not validate.

## Incident

None recorded.

## Screens

None.

## Not measured

Other tmux versions.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/012-tmux-refuses-access-and-exits-zero.md

# 012. tmux prints an access refusal and exits 0

## Measured

The first deployment of tg-bridge, in August 2026, with tmux 3.5a. The fact
records no exact date.

## What was measured

A tmux server accepts its own user only. Each other user gets `access not
allowed`, whatever the mode and the group of the socket permit. `tmux
server-access -a -w <user>` gives a user access, and only the owner of the
server can change that list. tmux prints the refusal and then exits 0.

## Mechanism

The exit status of tmux does not show an access refusal. A tool must assert a
result, for example the output of a query, and never the exit status alone.

## Incident

None recorded.

## Screens

None.

## Not measured

Other tmux versions.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/013-a-long-text-becomes-a-paste-marker.md

# 013. A long text becomes a paste marker

## Measured

2026-10-24, Claude Code 2.1.309 and agy 1.4.5, in a pane 120 columns wide.

## What was measured

`send-keys -l` typed text into an empty box. In Claude Code, text of 801
characters or more shows as `[Pasted text #N]`, and as `[Pasted text #N +K
lines]` when it holds K line breaks. Text of 800 characters or fewer stays
text, also on 60 lines. N counts the pastes of the process from 1. The Enter
submits the whole text. The prompt in the `UserPromptSubmit` hook holds that
text inside `<pasted_content id="…">` and `</pasted_content id="…">`.

agy 1.4.5 draws no marker: a text of 3000 characters stayed text.

## Mechanism

A tool that waits to see its own text in the box never sees a long text. It
accepts the marker as its text only when the box held no marker after the
clear, and the box then holds the marker alone.

## Incident

A message of 910 characters failed after the whole send timeout with "Nothing
was sent".

## Screens

`claude/paste`, `claude/paste-lines`, `claude/paste-and-text`.

## Not measured

Other pane widths. Whether the limit of 800 characters depends on the width.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/014-agy-reads-a-long-text-slowly.md

# 014. agy reads a long text slowly, and the Enter waits behind it

## Measured

2026-10-24, agy 1.4.5.

## What was measured

The Enter was sent when the first 60 characters were visible. The box was
empty after 0.56 s at most for 301 characters, 2.94 s for 901, 6.88 s for
1501, and 16.53 s for 3001. Each length had 5 samples, and every turn ran.
With an Enter after the whole text was visible, the box was empty after 0.11
to 0.14 s.

## Mechanism

The proof that the box emptied needs a budget that grows with the length of
the text. tg-bridge uses 1 s plus 8 ms for each character, up to 25 s.

## Incident

A proof with a budget of 1 s reported that it could not prove the submission
for 3 of 3 long texts that ran.

## Screens

None.

## Not measured

Other machines and other loads.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/015-a-dead-pane-reports-no-directory.md

# 015. A dead pane reports no directory

## Measured

2026-09-03, tmux 3.5a, with an isolated socket.

## What was measured

A pane that `remain-on-exit` holds gives `1` for `#{pane_dead}` and an empty
string for `#{pane_current_path}`. `respawn-pane -c .` starts the new process
in the working directory of the tmux CLIENT. The probe started the server in
directory A and ran the client from directory B. The pane started in directory
B.

## Mechanism

In many languages an empty path becomes `.`. A tool that restarts a dead pane
must keep the directory that the live pane reported, or use a known project
path. It must refuse the restart when it has neither.

## Incident

A restart sent `-c .`. The agent started in `/`, the default directory of the
service. `--continue` found no conversation there, the pane died again, and
the report named the conversation as the cause.

## Screens

None.

## Not measured

Other tmux versions.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/016-remote-control-draws-on-the-same-pane.md

# 016. Remote Control draws on the same pane

## Measured

2026-08-20 (Claude Code 2.1.238), 2026-09-01 (2.1.251), 2026-09-30 (2.1.284).

## What was measured

`claude --remote-control` gives a session a second control channel. It answers
to the Claude account of the session user, from claude.ai/code and the Claude
mobile app, and it acts on the same pane.

1. 2.1.238: a pane with the flag drew a `/rc` marker at the end of the footer.
   A plain pane drew none.
2. 2.1.251: a plain pane also drew the marker, and Remote Control was on by
   default. This measurement is superseded.
3. 2.1.284: a plain pane drew no marker, not the word `remote`, and no session
   address. A pane with the flag drew all three. The marker moved to the
   header line at the top of the pane, beside the working directory.

On 2.1.251 the `/remote-control` command opened a modal with "Disconnect this
session", "Show QR code" and "Continue". The mark started on "Continue". The
modal draws the input mark with no frame. Escape closed it.

## Mechanism

A tool that reads or drives a pane is not the only actor on it. The screen can
change between two reads for a reason that the tool did not cause. A reader
must give UNKNOWN for the Remote Control modal, and a tool must send no key to
it.

## Incident

None recorded.

## Screens

None. The corpus holds no capture of the modal yet.

## Not measured

A plain session on 2.1.284 that carries no channel is an inference from the
absence of its address. Nobody opened claude.ai/code for a plain session.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/017-the-agy-screen-shape.md

# 017. The screen shape of agy

## Measured

2026-10-23, agy 1.4.5, in a pane 120 columns wide.

## What was measured

agy draws the same input box as Claude Code: one rule of `─` above the input
line and one below it. Five details differ.

1. The mark is `>`, not `❯`. A message of the history also starts with `> `.
   The live box is the last one.
2. The footer of a busy pane is "esc to cancel". Claude Code draws that text
   under a permission dialog, and "esc to interrupt" during a turn.
3. A permission dialog has no frame: "Requesting permission for:", the
   command, "Run this command?", then numbered options. A digit answers it
   with no Enter.
4. The folder-trust menu starts on "Yes, I trust this folder" (fact 10).
5. The setup wizard (a colour scheme, then the terms of service) and the
   `/config` screen draw `>` with no frame and no numbered option.

## Mechanism

A reader for agy reads each line-starting `>` as the mark. It reads "esc to
cancel" as BUSY only under a framed box. It gives UNKNOWN for a setup screen,
because the answers of that screen belong to the operator. The frame test
stays last (fact 1).

## Incident

None recorded.

## Screens

`agy/idle`, `agy/typed`, `agy/busy`, `agy/permission`, `agy/trust`,
`agy/terms`, `agy/color-scheme`.

## Not measured

The trust menu with the mark on "No, exit". Other agy versions. Every corpus
screen of agy has shorter rules than the real screen.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/018-agy-draws-no-dialog-above-the-box.md

# 018. agy draws no dialog above a live box

## Measured

2026-10-24, agy 1.4.5, in a pane 120 columns wide.

## What was measured

Five shapes were checked for a dialog above a live input box (fact 2). None
does that. A dialog that asks (a file write, the question tool) draws IN PLACE
of the box. An overlay that lists items (`/model`, the `/` menu, the `?`
panel) draws BELOW the box, and its cursor line starts with `>`.

## Mechanism

For a dialog in place of the box, the last mark is the cursor of the dialog,
so it reads as a dialog. For an overlay below the box, the last mark is the
cursor of the overlay, with no frame, so it reads as UNKNOWN, and a tool sends
no key. The same screen cut below the box reads as IDLE, so the overlay alone
makes the state UNKNOWN.

## Incident

None recorded.

## Screens

`agy/file-permission`, `agy/question`, `agy/model-picker`, `agy/command-menu`,
`agy/shortcuts`.

## Not measured

Other agy dialogs. Other agy versions.

## Source

Measured by the tg-bridge project. The text is a summary of its notes, and it
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/019-the-codex-rollout-file-cannot-show-an-approval-wait.md

# 019. The Codex rollout file cannot show an approval wait

## Measured

2026-10-24, Codex CLI 0.163.0, a TUI that ran with `--no-daemon` in a
private tmux server.

## What was measured

Codex writes one rollout file for each session:
`~/.codex/sessions/YYYY/MM/DD/rollout-<time>-<session id>.jsonl`. The first
line is a `session_meta` record. It gives the session ID, the folder (`cwd`),
the originator (`codex-tui` for the TUI, `codex_exec` for a print run) and the
CLI version.

A command that needs an approval gave this order of records:

1. A `custom_tool_call` record for the command. Its `status` is already
   `completed`. Codex writes it before the approval dialog opens.
2. No record while the approval dialog waits.
3. After the approval: `function_call`, `function_call_output`, and at the
   end of the turn `task_complete`.

Thus a tool call with no output and no `task_complete` can mean an approval
wait or a command that still runs. The rollout file cannot tell the two
apart. The screen can: the approval dialog draws "Would you like to run the
following command?" in place of the input box (fact 20).

The rollout file of a TUI session can appear minutes after the session
starts. In one sample, the time in the file name was 5 minutes before the
first record and before the birth time of the file. Thus a reader can find no
rollout file for a session that runs, and the time in the file name is not
the time of the first write.

## Mechanism

Codex records the model output when it arrives. The approval is a state of
the TUI, and the file has no record for it.

## Incident

None recorded.

## Screens

`codex/approval`, `codex/approval-full`.

## Not measured

Which event makes Codex write the rollout file. The order of the records for a file-change approval. Other Codex versions.
A session that runs through the shared app-server daemon, without
`--no-daemon`. The records after a denied approval in the TUI.

## Source

Measured by the ai-world project during its M0 work (the order of the
records) and on 2026-10-24 (the late file). The Codex measurement report of
the tg-bridge project did not examine the order of the records. The text
holds no host details and no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/020-the-codex-screen-shape.md

# 020. The screen shape of Codex CLI

## Measured

2026-10-24, Codex CLI 0.163.0, `codex --no-daemon` in a private tmux server,
120 columns by 40 lines. The TUI uses the alternate screen, so the pane has
no scrollback.

## What was measured

Codex draws no frame around its input box. Seven details matter to a reader.

1. The mark is `›` (U+203A), not `❯` or `>`. A message of the history also
   starts with `› `. The live box is the last line that starts with the mark.
2. No rule of `─` is above or below the box. The frame test of fact 1 cannot
   prove an idle box.
3. Under an empty box, the last line starts with `? for shortcuts`. The line
   above it gives the model and the folder. The footer line is absent while
   the box holds text, and absent under a dialog.
4. A busy turn draws `• Working (1s • esc to interrupt)` directly above the
   box. The box, its placeholder and the footer stay drawn. A background
   command adds `· 1 background terminal running · /ps to view · /stop to
   close` to the same line.
5. The empty box shows a placeholder, for example `› Ask Codex to do
   anything`. In a plain capture it looks like typed text. With `-e`, the
   placeholder is dim and typed text is not.
6. The approval dialog draws in place of the box: "Would you like to run the
   following command?", `Environment: local`, `Reason: ...`, `$ <command>`,
   then numbered options under the mark, and the footer "Press enter to
   confirm or esc to cancel". The selected option is reverse video.
7. The folder-trust dialog comes before the first box in a folder that Codex
   has not seen: "Trust this folder? ...", `› 1. Trust and continue`,
   `2. Quit`, and the footer "enter continue · esc quit". The hooks review
   dialog ("Hooks need review") can come first in a project with untrusted
   hooks.

An update banner in a box of `╭─╮` draws at the top of each start. It is not
the input box.

## Mechanism

A reader for Codex proves an idle box with all of these: the last mark line
is not a numbered option, no line of the screen holds "esc to interrupt", and
the last nonblank line starts with `? for shortcuts`. It tests the busy line
before the idle footer, because the footer stays drawn during a turn. It
gives UNKNOWN for each other screen, for example a box with typed text. This
proof is weaker than a frame: a later dialog can draw the same footer.

## Incident

None recorded.

## Screens

`codex/idle`, `codex/typed`, `codex/busy`, `codex/busy-background`,
`codex/after-turn`, `codex/approval`, `codex/approval-full`,
`codex/after-cancel`, `codex/trust`, `codex/hooks-review`.

## Not measured

The keys of the approval dialog other than Esc. The file-change approval
dialog. A narrow pane where the busy line wraps. Styled captures of each
screen. Other Codex versions, and a TUI that runs through the shared
app-server daemon.

## Source

Measured by the tg-bridge project and published in its report "Codex CLI and
Cursor CLI as harnesses: measurements, 2026-10-24", with one more capture by
the ai-world project. The text is a summary, and it holds no host details and
no session details.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/021-a-cursor-cli-process-holds-its-chat-open.md

# 021. A Cursor CLI process holds its chat database open

## Measured

2026-10-30, Cursor CLI 2026.10.22-27dcf5f (nine processes) and
2026.10.01-e373342 (one process), on macOS 26.6 (arm64).
Measured on: real machine. The probe
`probes/cursor/macos.sh` read the open files with `lsof` and the folder
names with `ls`. It read no conversation text.

## What was measured

1. Each interactive Cursor CLI process keeps one chat database open:

   ```
   ~/.cursor/chats/<32 hex characters>/<chat id>/store.db
   ```

   The `store.db-shm` and `store.db-wal` files of the same chat are open
   too. Each of the ten interactive processes held exactly one chat.
2. The chat ID is the same as the ID of the transcript of that chat:

   ```
   ~/.cursor/projects/<project key>/agent-transcripts/<chat id>/<chat id>.jsonl
   ```

   One chat was checked by its ID in both paths.
3. Four processes in the same folder used the same `<32 hex characters>`
   folder. Processes in other folders used other ones. Thus the hex folder
   depends on the working folder. The hash function is not measured.
4. A file `meta.json` lies beside `store.db`. Its top-level fields are
   `createdAtMs`, `cwd`, `hasConversation`, `schemaVersion`, `title` and
   `updatedAtMs`.
5. A process also keeps `~/.cursor/ai-tracking/ai-code-tracking.db` open.
   One process kept a file `~/.cursor/projects/<project key>/terminals/<number>.txt`
   open.
6. `sqlite3 -readonly` could not open the newest `store.db` while its
   process ran: "unable to open database file".
7. The last records of a transcript can be `assistant` records with
   `tool_use` content, `assistant` records with `text`, and `user` records
   with `text`. A transcript of this version can also hold a record
   `{"type": "turn_ended", "status": "success"}` (seen in the shape report of
   a diagnostic tool, one record).

## Mechanism

A reader can bind a process to its transcript with no terminal screen and
no folder rule: it reads the open files of the process, takes the chat ID
from the `store.db` path, and opens the transcript with the same ID. This
works when several sessions run in the same folder. `meta.json` gives the
folder and the title of the chat.

## Incident

None. Before this fact, a reader bound a Cursor CLI transcript only through
the folder of a tmux pane. On a Mac with no tmux it showed no Cursor session.

## Screens

None.

## Not measured

- Whether the process opens a new `store.db` after `/new-chat` or `--resume`,
  and whether it closes the old one.
- The hash function of the hex folder.
- Linux and Windows.
- The editor's agent workers (fact 22) held no `store.db` open when the
  probe ran.
- Whether the transcript shows a wait on a permission dialog.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/022-cursor-cli-terminals-on-macos.md

# 022. The terminals and the worker processes of the Cursor CLI on macOS

## Measured

2026-10-30, Cursor CLI 2026.10.22-27dcf5f, Cursor editor (version not
recorded), macOS 26.6 (arm64), with no tmux installed.
Measured on: real machine. The probe
`probes/cursor/macos.sh` read `ps` and one AppleScript call to Terminal.

## What was measured

1. An interactive Cursor CLI process runs as
   `~/.local/bin/agent --use-system-ca ~/.local/share/cursor-agent/versions/<version>/index.js`.
   Its parent is the shell of the terminal (`zsh`). It has a tty, for example
   `ttys023`.
2. The parent of that shell is the terminal program:
   - A JetBrains IDE (PyCharm) for nine processes: `pycharm` > `/bin/zsh` >
     `agent`.
   - Terminal.app for one process: `Terminal` > `login` > `-zsh` > `agent`.
3. `osascript -e 'tell application "Terminal" to get tty of every tab of every window'`
   gives the tty of each Terminal tab, for example `/dev/ttys001`. The tty of
   the Terminal process in item 2 was in that list.
4. The Cursor editor runs agent workers as
   `~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/bin/cursor-agent`.
   Their parent is process 1, and they have no tty. Each one has a working
   folder. Four ran at the same time.
5. The editor runs an extension host with the title "Agents Window".

## Mechanism

The tty of a process names its terminal tab. Terminal.app can find a tab by
its tty, so a tool can bring that tab to the front. A JetBrains IDE has no
known scripting access to its terminal tabs, so a tool can only bring the
window of the IDE to the front.

The editor's agent workers are not CLI sessions: no person types in them.
A reader of CLI sessions must not show them as sessions.

## Incident

None.

## Screens

None.

## Not measured

- iTerm2, Ghostty, WezTerm, kitty and Warp (not installed).
- Whether a JetBrains IDE can select a terminal tab from a script.
- What the editor's agent workers do, and whether they write transcripts.
- Linux and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/023-the-claude-pid-file-shows-a-dialog-wait.md

# 023. The Claude pid file shows a dialog wait

## Measured

2026-10-30, Claude Code 2.1.314, on Linux (Debian 13, x64), in a private
tmux server with a throwaway `HOME` and a copied login. The scenario
`scenarios/claude/permission-dialog.sh` read the file at each step and
every 2 s while a dialog waited. Live sessions of 2.1.310 and 2.1.314 on
the same machine gave the field list and the `busy` value.
Measured on: real machine.

## What was measured

1. Each interactive process writes `~/.claude/sessions/<pid>.json`. Its
   fields are `pid`, `sessionId`, `cwd`, `startedAt`, `procStart`,
   `version`, `kind` (`interactive`), `entrypoint` (`cli`), `status`,
   `statusUpdatedAt`, `updatedAt`, `name`, `tmux`, `messagingSocketPath`,
   and others.
2. `status` had four values:

   | Value | When |
   |---|---|
   | `idle` | The input box waits for a prompt. |
   | `busy` | A turn runs. |
   | `waiting` | A permission dialog waits. |
   | `shell` | Seen in a live session of 2.1.310 that ran shell commands for a long time. The cause is not measured. |

   The value changed to `waiting` when the dialog opened. It stayed
   `waiting` for the whole wait (5 reads in 10 s). It changed to `idle`
   after an answer: "1. Yes", and also Esc.
3. `sessionId` is the `session_id` of the hooks. The transcript file name
   holds the same ID. After `/clear`, `sessionId` changed to the ID of the
   new session.
4. `tmux` has the form `<session>:@<window id>.%<pane id>` when the process
   runs in tmux. It is empty when the process does not have `TMUX` and
   `TMUX_PANE` in its environment.
5. While the folder-trust question waits, there is no `<pid>.json`. Only
   `~/.claude/sessions/<pid>.<64 hex characters>.key` exists. `<pid>.json`
   appears after the answer. No hook fires before the answer.

## Mechanism

A reader can link a process to its session with no screen: it takes the
pid of the pane process, reads `<pid>.json`, and gets `sessionId` and
`status`. `claude --resume <sessionId>` then resumes that exact session,
not the last session of the folder.

A process with a `.key` file and no `.json` file waits on the trust
question, or has just started.

## Incident

None. tg-bridge and aw asked for these signals: a signal for the trust
wait, an exact link from a pane to its session, and a dialog wait with no
screen parse.

## Screens

None.

## Not measured

- Whether `status` is `waiting` for other dialogs: a question from the
  agent, an MCP dialog, a plan approval.
- How long `.key` exists alone after a normal start, with a folder that is
  already trusted.
- macOS and Windows.
- What happens to `<pid>.json` after a crash.

## 2026-10-30, 2.1.314: more waits, and a resume

Measured on: real machine. Scenarios `scenarios/claude/dialog-states.sh`
(three runs) and `scenarios/claude/plan-and-resume.sh` (one run), on the
same Linux machine. They read the file every 1 s while each wait lasted.

1. `status` is `waiting` also for a question from the agent, a Bash
   command dialog, and a plan approval. A field `waitingFor` is in the
   file while `status` is `waiting`: `input needed` for a question, and
   `permission prompt` for a tool dialog or a plan approval (fact 031).
2. `shell` means: no turn runs, and a background shell of the session
   still runs. A background `sleep 30` gave `busy`, then `shell` for
   26 to 27 s, then `busy` for the turn that the task notification starts,
   then `idle` (fact 031). The `shell` row of the table above, "The cause
   is not measured", is superseded.
3. After "No" on a Bash dialog, `status` was `idle` from 1 s after the
   key (fact 033).
4. After `/exit`, `<pid>.json` and the `.key` file were gone. A new
   process with `claude --resume <sessionId>` wrote a new `<pid>.json`
   with a new pid and the same `sessionId` (fact 035).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/024-the-claude-permission-hooks.md

# 024. The Claude hooks around a permission dialog

## Measured

2026-10-30, Claude Code 2.1.314 with `--permission-mode default`, on Linux
(Debian 13, x64), in a private tmux server with a throwaway `HOME`. The
scenario `scenarios/claude/permission-dialog.sh` recorded every hook
payload. The prompt asked for a new file in an empty folder.
Measured on: real machine.

## What was measured

1. A new install starts in auto mode. In auto mode the file write ran with
   no dialog. With `--permission-mode default` it opened the dialog
   "Do you want to create note.txt?" with three options: "1. Yes",
   "2. Yes, and switch to accept edits ...", "3. No".
2. The hooks fired in this order:

   | Step | Hooks |
   |---|---|
   | The dialog opens | `PreToolUse`, `PermissionRequest`, `Notification` |
   | Esc on the dialog | none |
   | "1. Yes" on the dialog | `PostToolUse`, `Stop` |

3. The `PermissionRequest` payload has `tool_name`, `tool_input`,
   `permission_suggestions`, `permission_mode`, `session_id`,
   `transcript_path`, `cwd`, `prompt_id` and `effort`. The suggestion was
   `{"type": "setMode", "mode": "acceptEdits", "destination": "session"}`.
   That is option 2. The payload does not hold the question text or the
   option labels.
4. The `Notification` payload has `notification_type: permission_prompt`
   and `message: Claude needs your permission`.
5. After Esc, no `Stop` hook fired. The next hook was the
   `UserPromptSubmit` of the next prompt.
6. `/clear` fired `SessionEnd` with `reason: clear`, and then
   `SessionStart` with `source: clear` and a new `session_id`.

## Mechanism

A reader learns that a dialog is open from `PermissionRequest` or from the
`Notification` of type `permission_prompt`. It can build the buttons from
`tool_name`, `tool_input` and `permission_suggestions`, but the labels and
the number of options come only from the screen.

A reader that waits for `Stop` after a denial waits for ever. The pid file
(fact 023) changes to `idle` after a denial.

## Incident

A tg-bridge parse of the dialog options failed when an option wrapped to
a second line. This fact shows which part of the dialog the hooks give.

## Screens

None.

## Not measured

- A denial with "3. No" instead of Esc.
- A Bash command dialog, and dialogs with more than three options.
- Whether a `PermissionRequest` hook can answer the dialog by its output.
- macOS and Windows.

## 2026-10-30, 2.1.314: a question, a plan, and a Bash dialog

Measured on: real machine. Scenarios `scenarios/claude/dialog-states.sh`
(three runs) and `scenarios/claude/plan-and-resume.sh` (one run), on the
same Linux machine.

1. A question from the agent (`AskUserQuestion`) fires `PreToolUse`,
   `PermissionRequest` and `Notification` (`permission_prompt`), as a
   permission dialog does. Its `tool_input` holds the question text, the
   header, and the label and description of each option (fact 032). This
   is a structured record of the dialog with its options. Claude Code adds
   two rows that are not in `tool_input`.
2. A plan approval (`ExitPlanMode`) fires the same three hooks. Its
   `tool_input` has `plan` and `planFilePath`, and no option labels
   (fact 032).
3. A Bash command dialog has four options: "1. Yes", "2. Yes, and always
   allow access to ...", "3. Yes, and switch to auto mode", "4. No". "3."
   approves the command and turns on auto mode. "4. No" fires no hook and
   no `Stop`, the same as Esc (fact 033). The "Not measured" items "A
   denial with "3. No" instead of Esc" and "A Bash command dialog" above
   are measured now.
4. When a background shell ends, Claude Code starts a turn by itself.
   It fires `UserPromptSubmit` with a `<task-notification>` prompt, and
   `Stop`. The `Stop` payload has `background_tasks` (fact 031).
5. After `claude --resume <sessionId>`, `SessionStart` fired with
   `source: resume`. After `/exit`, `SessionEnd` fired with
   `reason: prompt_input_exit` (fact 035).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/025-a-claude-process-holds-its-task-folder-open.md

# 025. A Claude process holds its task folder open

## Measured

2026-10-30, Claude Code 2.1.310 and 2.1.314, on Linux (Debian 13, x64).
Two live interactive sessions in tmux. `readlink` read each entry of
`/proc/<pid>/fd`.
Measured on: real machine.

## What was measured

1. A Claude process holds no transcript file open.
2. It holds one folder open:
   `/tmp/claude-<uid>/<project key>/<session id>/tasks`. The session ID in
   that path is the `sessionId` of `~/.claude/sessions/<pid>.json`
   (fact 023).
3. Its other descriptors are its tty (8 descriptors), sockets, and
   `anon_inode` entries (`eventpoll`, `eventfd`, `pidfd`).

## Mechanism

A reader that can read the open files of a process, but not the home
folder of its user, can still get the session ID from the task folder.

## Incident

None.

## Screens

None.

## Not measured

- Whether the folder changes after `/clear`.
- Sessions with no background task. Both sessions had run tasks.
- The path on macOS and Windows, where the temporary folder is different.

## 2026-10-30, 2.1.314: before the first task, and after /clear

Measured on: real machine. Scenario `scenarios/claude/dialog-states.sh`
(three runs) in a throwaway `HOME`, on the same Linux machine.

1. Before the first Bash tool call, the process held no folder below
   `/tmp/claude-<uid>/` open, and the `tasks` folder did not exist. The
   first Bash call made the folder and opened it. That call was a
   foreground `ls`, not a background task (fact 034).
2. After `/clear`, the process still held the `tasks` folder of the first
   session ID. A background task after `/clear` wrote its output there.
   So the session ID in the path is the first session ID of the process,
   not always the `sessionId` of the pid file. The Mechanism above is
   correct only for a process that has had one session (fact 034).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/026-the-codex-daemon-holds-the-rollout-files.md

# 026. The Codex daemon holds the rollout files

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install, x86_64-unknown-linux-musl),
on Linux (Debian 13, x64), in a private tmux server with a throwaway
`HOME` and a copied login. The scenarios `scenarios/codex/approval.sh`
(with and without `--no-daemon`) and `scenarios/codex/two-sessions.sh`
read `/proc/<pid>/fd` of each process at each step.
Measured on: real machine.

## What was measured

1. In the default mode, the TUI starts an app-server daemon:
   `~/.codex/packages/app-server-daemon/releases/<version>-<target>/bin/codex app-server --listen unix:// --analytics-default-enabled --managed-daemon`.
   It has no tty. Its parent is the TUI. A second child,
   `codex app-server daemon pid-update-loop`, also starts.
2. The daemon, not the TUI, holds the session files open:
   - `~/.codex/thread-writer-locks/<session id>.lock`, from the start of
     the session, before the first prompt.
   - `~/.codex/sessions/YYYY/MM/DD/rollout-<time>-<session id>.jsonl`, from
     the first prompt.
   The TUI holds neither file.
3. Two TUIs with the same `HOME` share one daemon. The daemon is a child
   of one of the two TUIs. It holds the lock and the rollout file of both
   sessions.
4. After the TUI exits, the daemon keeps running. Its parent becomes
   process 1. It keeps the lock and the rollout file of the ended session
   open.
5. `codex resume --last` uses the daemon that runs. It appends to the same
   rollout file. It makes no new file. No process in the tree of the
   resumed TUI holds the file.
6. With `--no-daemon`, the TUI itself holds the lock from the start and the
   rollout file from the first prompt. `resume` also appends to the same
   file in this mode.

## Mechanism

The daemon writes the sessions for all TUIs of one `HOME`. Thus an open
rollout file in the process tree of a TUI does not prove that the session
belongs to that TUI, and an open rollout file does not prove that its
session is live. Only with `--no-daemon` does an open file link one TUI to
one session.

The session ID in the lock file name is known before the first prompt,
when no rollout file exists yet.

## Incident

aw planned an exact binding from a Codex TUI to its rollout file through
the open files of the process tree. In the default mode that binding can
pick the session of another TUI.

## Screens

None.

## Not measured

- macOS and Windows.
- Whether a file links a TUI to its thread in daemon mode, for example
  `~/.codex/state_5.sqlite`. It was not read.
- When the daemon exits after the last TUI exits. It still ran 20 s after.
- The sandbox helper: on this machine `bwrap` could not make a namespace,
  so the commands ran with no sandbox helper process.

## Later measurement, 2026-10-30 (0.164.0)

The scenario `scenarios/codex/daemon-life.sh` measured three items of the
list above. Fact 39 and fact 40 give the details.

- The life of the daemon: it did not exit in the 300 s after the last TUI
  exited, in two runs. A TUI that started 30 s after the last exit used
  the same daemon. About 6 minutes after its start, the daemon replaced
  itself with a daemon of a newer version (0.166.0), with a new pid. The
  new daemon held no file of the ended sessions.
- A `--no-daemon` TUI next to a running daemon holds its own rollout file
  and lock. The daemon does not hold them.
- The layout of `~/.codex/state_5.sqlite` and of the other databases has
  no column for a pid or a client of the daemon. Only `logs` in
  `logs_2.sqlite` joins a `process_uuid` to a `thread_id`. The rows were
  not read.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/027-the-codex-rollout-shows-an-aborted-turn.md

# 027. The Codex rollout file shows an aborted turn

## Measured

2026-10-30, Codex CLI 0.164.0, on Linux (Debian 13, x64), with
`--sandbox read-only --ask-for-approval on-request`, in a private tmux
server with a throwaway `HOME`. The scenario `scenarios/codex/approval.sh`
recorded the record types of the rollout file at each step, with and
without `--no-daemon`. It read no content.
Measured on: real machine.

## What was measured

1. A prompt that asked for a new file opened the dialog "Would you like to
   run the following command?" with "1. Yes, proceed (y)",
   "2. Yes, and don't ask again ...", and "3. No, and tell Codex what to do
   differently (esc)".
2. Esc on the dialog added these records, in this order:
   `response_item` `custom_tool_call_output`, `event_msg` `token_count`,
   `response_item` `message`, `event_msg` `turn_aborted`.
   The screen showed "Conversation interrupted".
3. A turn that ended normally had an `event_msg` `task_complete` record.
4. Both modes (daemon and `--no-daemon`) gave the same records.

## Mechanism

A reader of the rollout file sees the end of a turn in both cases:
`task_complete` after a normal end, `turn_aborted` after Esc. This does not
depend on the Stop hook, which tg-bridge measured does not fire after Esc
or a denial.

## Incident

tg-bridge did not learn that a Codex turn ended after Esc on an approval
dialog, because no Stop hook fired.

## Screens

None.

## Not measured

- "3. No" with a typed answer, and Ctrl+C during a turn.
- An Esc during a running command, with no dialog.
- macOS and Windows.

## Later measurement, 2026-10-30 (0.164.0)

The scenarios `scenarios/codex/deny.sh` and `scenarios/codex/interrupt.sh`
measured the first two items of the list above. Facts 36, 37 and 38 give
the details.

- The digit `3` ("No, and tell Codex what to do differently") acts at
  once and gives the same four records as Esc, with `turn_aborted` last.
  Codex asks for no text. The turn ends.
- Esc while an approved command runs gives the same four records.
- Ctrl+C during a turn does not stop it. It opens the dialog "Task is
  still running". `1. Cancel task` and `3. Exit` give `turn_aborted`. Esc
  on that dialog lets the turn go on to `task_complete`.
- Codex 0.164.0 has an `Interrupt` hook. It fires in each case that writes
  `turn_aborted`. `Stop` does not fire in these cases.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/028-the-agy-turn-signals.md

# 028. The agy hooks and files of a turn

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64), in a
private tmux server with a throwaway `HOME` and a copied login. The
scenario `scenarios/agy/turn-signals.sh` set a hook for each of the six
events in `~/.gemini/config/hooks.json`, and recorded at each step the
screen, the open files of the process, and the record types of the
transcript. It read no content.
Measured on: real machine.

## What was measured

1. agy 1.4.7 knows six hook events: `SessionStart`, `PreInvocation`,
   `PostInvocation`, `PreToolUse`, `PostToolUse` and `Stop`. The file has
   one object for each hook group:
   `{"<group>": {"<event>": [{"type": "command", "command": "...", "timeout": 10}]}}`.
2. The hooks fired in this order:

   | Step | Hooks |
   |---|---|
   | The process starts | none |
   | The first prompt | `SessionStart`, then `PreInvocation` |
   | A file dialog opens ("Allow creation of this file?") | none |
   | Esc on the dialog | none |
   | The next prompt | `PreInvocation` |
   | The turn ends | `PostInvocation`, then `Stop` |

   `PreToolUse` and `PostToolUse` did not fire for the file write, with
   the hook shape of item 1.
3. Each payload has `conversationId`, `transcriptPath`,
   `artifactDirectoryPath`, `workspacePaths`, `lastUserInput` and
   `modelName`. `PreInvocation` and `PostInvocation` add `invocationNum`
   and `initialNumSteps`. `Stop` adds `executionNum`, `fullyIdle`
   (`true`), `terminationReason` (`NO_TOOL_CALL`) and `error` (empty).
   The hook process has `ANTIGRAVITY_CONVERSATION_ID` in its environment.
4. From the first prompt until the process exits, the process holds these
   files open:
   - `~/.gemini/antigravity-cli/conversations/<conversation id>.db`, with
     its `-wal` and `-shm` files.
   - `~/.gemini/antigravity-cli/presence/<conversation id>.lock`.
   Before the first prompt it holds neither file.
5. The transcript is
   `~/.gemini/antigravity-cli/brain/<conversation id>/.system_generated/logs/transcript.jsonl`.
   Each turn added a `USER_INPUT` record and a `PLANNER_RESPONSE` record.
   Esc on the dialog added no record.
6. A new install shows a wizard: a colour page, then a terms page. The
   terms page has a box, checked by default, that agrees to the collection
   of interaction data. The scenario clears it. Down, then Right, selects
   "Done".

## Mechanism

A reader can link a process to its conversation with no screen: the
conversation ID is in the names of the open `presence` and `conversations`
files. `PreInvocation` shows the start of a turn, and `PostInvocation` or
`Stop` shows its end.

An Esc gives no hook and no transcript record. A reader that waits for
`Stop` after an Esc waits for ever. Only the screen shows the end of that
turn.

## Incident

tg-bridge has only screen rules for agy. agy 1.4.7 `--continue` in an
empty folder draws an empty box that looks idle.

## Screens

None.

## Not measured

- A hook shape with a `matcher` for `PreToolUse` and `PostToolUse`.
- "2. No, deny creation" instead of Esc.
- Whether the `presence` lock is an advisory lock (`flock`) that a reader
  can test.
- `--continue` and `--conversation <id>`.
- macOS and Windows.

## Later measurement (2026-10-30, agy 1.4.7)

The scenarios `scenarios/agy/deny-and-tools.sh` and
`scenarios/agy/continue.sh` measured four items of "Not measured" above.
The items above stay as they were measured.

1. `PreToolUse` and `PostToolUse` fire when each handler list is in a group
   with a `matcher`:
   `{"<group>": {"PreToolUse": [{"matcher": "*", "hooks": [{"type": "command", "command": "...", "timeout": 10}]}]}}`.
   Item 2 above used the flat shape, which agy does not read for these two
   events. See fact 42.
2. "2. No, deny creation" fires no hook after `PreToolUse`, as an Esc. It
   adds a `GENERIC` record with `status` `ERROR` to the transcript. See
   fact 41.
3. The `presence` file is a `flock` lock, held while the process runs. See
   fact 44.
4. `--continue` and `--conversation <id>` reuse the `presence` and
   `conversations` files of the conversation, and open them at the start,
   before the first prompt. This changes item 4 above for such a process.
   `SessionStart` does not fire again. See fact 43.
5. `conversation_summaries.db` shows a running turn and the end of a turn,
   also after an Esc. See fact 45.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/029-the-first-start-with-no-login.md

# 029. The first start of each agent with no login

## Measured

2026-10-30, the scenario `scenarios/first-run.sh` in the scenarios
workflow (run 41126049221), with a throwaway `HOME`, no login and no key.
Each agent was installed on the runner by the workflow:

| Agent | Version | Install |
|---|---|---|
| Claude Code | 2.1.314 | npm `@anthropic-ai/claude-code` |
| Codex CLI | 0.166.0 | npm `@openai/codex` |
| Cursor CLI | 2026.10.22-27dcf5f | `curl https://cursor.com/install` |
| opencode | 1.19.5 | npm `opencode-ai` |

Measured on: CI runner ubuntu-latest (x64) and CI runner macos-latest
(arm64). The two runners gave the same screens and the same files.

## What was measured

1. Claude Code first shows "Choose the text style that looks best with your
   terminal", with "Dark mode" selected. Below `~/.claude` it made only
   `sessions/<pid>.<hex>.key`, `backups/`, `cache/changelog.md`, and
   `~/.claude.json`. There is no `sessions/<pid>.json`, as before the trust
   answer in fact 23.
2. Codex CLI first shows "Choose how you want to use Codex." with
   "1. Sign in with ChatGPT", "2. Sign in with Device Code", "3. Use an
   OpenAI API key" and "4. Use Amazon Bedrock". Only the TUI runs: no
   app-server daemon starts before a login. The TUI holds the SQLite files
   `state_5`, `logs_2`, `goals_1`, `memories_1` and `queue_1` below
   `~/.codex` open. It made about 5,500 files in `~/.codex/.tmp/plugins`.
   The npm install runs the binary from
   `node_modules/@openai/codex/node_modules/@openai/codex-<os>-<cpu>/vendor/<target>/bin/`.
3. Cursor CLI shows "Press any key to log in...". It made
   `~/.cursor/agent-cli-state.json`, `cli-config.json` and
   `statsig-cache.json`. The process is
   `~/.local/bin/cursor-agent --use-system-ca ~/.local/share/cursor-agent/versions/<version>/index.js`.
4. opencode 1.19.5 holds `~/.local/share/opencode/opencode.db` (with
   `-wal` and `-shm`) and `log/opencode.log` open. It made a Node project in
   `~/.config/opencode` with about 3,600 files in `node_modules`. Its screen
   says "/update to upgrade to OpenCode 2.0". The npm package `opencode-ai`
   is the 1.x line; the operator's server runs opencode 2.1.4.

## Mechanism

A tool that sees a new process of one of these agents with no session file
can show "waits for setup or login" in place of "idle". The screens above
are the first screens a person sees after an install.

## Incident

None.

## Screens

None. The screens are in the log of the run, not in the corpus.

## Not measured

- agy: no install command for a runner is known.
- Windows.
- The screens after the first choice (theme, sign-in method).
- opencode 2.x on a runner.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/030-the-first-start-of-four-more-agents.md

# 030. The first start of Gemini CLI, Copilot CLI, Qwen Code and Aider

## Measured

2026-10-30, the scenario `scenarios/first-run.sh <agent> <command>` in the
scenarios workflow (run 41127387845), with a throwaway `HOME`, no login and
no key. Each agent was installed on the runner by the workflow:

| Agent | Version | Install |
|---|---|---|
| Gemini CLI | 0.66.0 | npm `@google/gemini-cli` |
| GitHub Copilot CLI | 1.0.105 | npm `@github/copilot` |
| Qwen Code | 0.26.4 | npm `@qwen-code/qwen-code` |
| Aider | 0.86.2 | pipx `aider-chat` (Linux only) |

Measured on: CI runner ubuntu-latest (x64) and CI runner macos-latest
(arm64). Gemini CLI, Copilot CLI and Qwen Code gave the same screens and
files on both. The Aider install failed on macOS: pip could not build
`numpy==1.24.3`.

## What was measured

1. Copilot CLI asks "Confirm folder trust" before a login, with
   "1. Yes", "2. Yes, and remember this folder for future sessions" and
   "3. No (Esc)". It runs as `node .../bin/copilot` with a native child
   `.../@github/copilot-<os>-<cpu>/copilot`. The child holds
   `~/.copilot/session-state/<session id>/inuse.<pid>.hold` open, where
   `<pid>` is its own pid. It also writes `~/.copilot/config.json`,
   `open-sessions-state.json` and `logs/process-<time>-<pid>.log`.
2. Gemini CLI asks "Do you trust the files in this folder?" before a login,
   with "1. Trust folder (<name>)", "2. Trust parent folder (<name>)" and
   "3. Don't trust". It runs as two node processes (the second with
   `--max-old-space-size`). It writes below `~/.gemini`: `tmp/<folder
   name>/`, `history/<folder name>`, `projects.json`, `state.json` and
   `installation_id`. It held no file below `~/.gemini` open.
3. Qwen Code first shows a choice of the provider ("Choose a built-in
   provider and connect with an API key", "Custom Provider"). It runs as
   one node process and holds `~/.qwen/settings.json`,
   `model-registry.json` and `installation_id` open.
4. Aider first asks "No git repo found, create one to track aider's changes
   (recommended)? (Y)es/(N)o [Yes]:". It runs as a Python process. It
   writes `~/.aider/analytics.json` and `caches/versioncheck`.

## Mechanism

Copilot CLI gives an exact link from a process to its session in the name
of a file that the process holds open: the session ID is the folder, and
the pid is in the file name.

Gemini CLI and agy (fact 28) both use `~/.gemini`. agy keeps its files in
`~/.gemini/antigravity-cli` and `~/.gemini/config`. A reader must not mix
them.

## Incident

None.

## Screens

None. The screens are in the log of the run, not in the corpus.

## Not measured

- The screens after a login, and any turn.
- Whether the Copilot `inuse.<pid>.hold` file stays the same after a new
  session in the same process.
- Aider on macOS.
- Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/031-the-claude-pid-file-names-the-wait.md

# 031. The Claude pid file names the wait and a background shell

## Measured

2026-10-30, Claude Code 2.1.314 with `--model haiku`, on Linux (Debian 13,
x64), in a private tmux server with a throwaway `HOME` and a copied login.
The scenarios `scenarios/claude/dialog-states.sh` (three runs) and
`scenarios/claude/plan-and-resume.sh` (one run) read
`~/.claude/sessions/<pid>.json` every 1 s while each wait lasted. They
kept one copy of the file for each status and recorded every hook payload.
Measured on: real machine.

## What was measured

1. The `status` field and a `waitingFor` field had these values:

   | Wait | `status` | `waitingFor` |
   |---|---|---|
   | The input box waits for a prompt | `idle` | not in the file |
   | A turn runs | `busy` | not in the file |
   | A question from the agent (`AskUserQuestion`) | `waiting` | `input needed` |
   | A Bash command dialog | `waiting` | `permission prompt` |
   | A plan approval (`ExitPlanMode`) | `waiting` | `permission prompt` |
   | The turn ended, and a background shell runs | `shell` | not in the file |

   `status` stayed `waiting` for each read of the wait: 10 reads in 10 s
   for each dialog. The `waitingFor` field is in the file only while
   `status` is `waiting`.
2. The prompt "Run the command sleep 30 with your Bash tool in the
   background ..." gave this order of `status` values, read every 1 s:
   `busy` for 2 to 4 s, `shell` for 26 to 27 s, `busy` for 2 s, then
   `idle`. This order was the same in the three runs. With `sleep 3`,
   `shell` lasted 1 to 2 s. So `shell` means: no
   turn runs, and a background shell of the session still runs. This
   explains the `shell` value of fact 023.
3. When the background shell ends, Claude Code starts a new turn by
   itself. That is the second `busy`. The hooks for that turn are
   `UserPromptSubmit`, whose `prompt` starts with `<task-notification>`,
   and then `Stop`. No key was sent for that turn.
4. The `Stop` payload has a `background_tasks` list. At the end of the
   turn that started the shell, it had one item with the keys `id`,
   `type` (`shell`), `status` (`running`), `description` and `command`.
   The `id` is the `backgroundTaskId` of the `PostToolUse` `tool_response`
   of that Bash call. At the end of the turn that the task notification
   started, the list was empty. `Stop` also has `session_crons` (an empty
   list in each run) and `stop_hook_active` (`false`).
5. After "1." on the plan approval, `status` was `waiting` for one more
   read (1 s), then `busy`, then `idle`.
6. The other fields of the file in 2.1.314: `peerProtocol`,
   `peerFeatures`, `pidDomain`, `asksForConvertedSkills`, `nameSource`
   and `nameSince`, next to the fields of fact 023.

## Mechanism

A reader can tell a question from a permission dialog with no screen:
`waitingFor` is `input needed` for a question, and `permission prompt`
for a tool dialog or a plan approval. The reader cannot tell a plan
approval from a tool dialog by the pid file.

A reader must not show `shell` as a wait for the operator. The agent
starts its next turn by itself when the shell ends. A reader that wants
the task list reads `background_tasks` from `Stop`.

## Incident

None. tg-bridge and aw asked which dialog waits, and what `shell` means.

## Screens

None.

## Not measured

- An MCP dialog, a question wizard of more than one question, and a
  dialog of a subagent.
- A background shell that runs while a turn also runs.
- A background shell that the operator stops, and a shell that fails.
- Whether `waitingFor` has other values.
- Other models, macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/032-the-claude-question-hooks-carry-the-options.md

# 032. The Claude question hooks carry the question and the options

## Measured

2026-10-30, Claude Code 2.1.314 with `--model haiku` and
`--permission-mode default` (the question) or `--permission-mode plan`
(the plan), on Linux (Debian 13, x64), in a private tmux server with a
throwaway `HOME`. The scenarios `scenarios/claude/dialog-states.sh` (three
runs) and `scenarios/claude/plan-and-resume.sh` (one run) recorded every
hook payload. The scenarios print only the keys and the shape of
`tool_input`.
Measured on: real machine.

## What was measured

1. The prompt "Ask me with your question tool whether I prefer red or
   blue, then reply with my answer." opened this dialog:

   ```
    ☐ Color
   Do you prefer red or blue?
   ❯ 1. Red
        You prefer red.
     2. Blue
        You prefer blue.
     3. Type something.
   ────────────────────────────
     4. Chat about this
   Enter to select · ↑/↓ to navigate · Esc to cancel
   ```

2. The hooks for the question fired in this order: `PreToolUse`,
   `PermissionRequest`, `Notification` (`notification_type:
   permission_prompt`), and after "1." `PostToolUse`, then `Stop`.
3. `PreToolUse` and `PermissionRequest` have `tool_name: AskUserQuestion`
   and a `tool_input` of this shape:

   ```
   {"questions": [{"question": str, "header": str,
                   "options": [{"label": str, "description": str}, ...],
                   "multiSelect": bool}]}
   ```

   In each run there was one question with two options. `question` was
   the dialog line "Do you prefer red or blue?", `header` was "Color",
   and the labels were "Red" and "Blue", each with its description line.
   `PermissionRequest` has no `permission_suggestions` for this tool.
4. The rows "3. Type something." and "4. Chat about this" are not in
   `tool_input`. Claude Code adds them. Two options in `tool_input` gave
   four numbered rows on the screen.
5. The `PostToolUse` `tool_input` and `tool_response` have the same
   `questions`, and also `answers` and `annotations`. `answers` maps the
   question text to the label of the answer.
6. A single question with a digit answer opened no review screen. The
   digit "1" closed the dialog at once (fact 004).
7. The plan approval. In plan mode the agent wrote the plan file with the
   `Write` tool, and then called `ExitPlanMode`. The hooks were
   `PreToolUse`, `PermissionRequest` and `Notification`
   (`permission_prompt`). The `tool_input` keys were `plan` (the plan
   text) and `planFilePath` (`~/.claude/plans/<name>.md`).
   `PermissionRequest` had no `permission_suggestions`. The dialog was:

   ```
    Claude has written up a plan and is ready to execute. Would you like to proceed?
    ❯ 1. Yes, and use auto mode
      2. Yes, manually approve edits
      3. Tell Claude what to change
         shift+tab to approve with this feedback
   ```

   After "1.", `PostToolUse` had an empty `tool_input` and a
   `tool_response` with `plan`, `isAgent` and `filePath`. The
   `permission_mode` of the next hooks was `auto`.

## Mechanism

A reader can build a structured record of a question from `PreToolUse` or
`PermissionRequest` with no screen parse: the question, the header, the
labels, the descriptions, and `multiSelect`. It must add the two rows that
Claude Code draws: a free-text row and "Chat about this". In the measured
dialog, the digit of option N of `tool_input` was N.

For a plan approval the hooks give the plan text, not the option labels.
The labels come only from the screen.

## Incident

None. tg-bridge asked for a structured record of a dialog with its
options.

## Screens

None.

## Not measured

- A question with `multiSelect: true`, and a wizard of more than one
  question in 2.1.314.
- An answer with "Type something." or "Chat about this", and Esc on the
  question.
- Answers "2." and "3." on the plan approval.
- Other models, macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/033-the-claude-bash-dialog-has-four-options.md

# 033. The Claude Bash dialog has four options, and "3." is not "No"

## Measured

2026-10-30, Claude Code 2.1.314 with `--model haiku` and
`--permission-mode default`, on Linux (Debian 13, x64), in a private tmux
server with a throwaway `HOME`. The scenario
`scenarios/claude/dialog-states.sh` ran three times. It recorded every
hook payload, and read the pid file every 1 s for 10 s after each answer.
Measured on: real machine.

## What was measured

1. The commands `ls` and `sleep 30` (in the background) ran with no
   dialog in the default mode. Each gave `PreToolUse` and `PostToolUse`,
   and no `PermissionRequest`.
2. The command `mkdir build` opened this dialog (the path is shortened):

   ```
    Bash command
    Tip: auto mode handles these prompts for you — choose "switch to auto mode" below
    Create build directory in the work folder
    mkdir /work/example/build
    Do you want to proceed?
    ❯ 1. Yes
      2. Yes, and always allow access to /work/example from this
      3. Yes, and switch to auto mode · auto mode handles these prompts for you
      4. No
    Esc to cancel · Tab to amend
   ```

   The file-write dialog of fact 024 has three options, and its "3." is
   "No". The Bash dialog has four options, and its "No" is "4.".
3. In run 2, the scenario sent "3" to this dialog. The command ran, and
   the mode changed to auto mode for the rest of the session. The screen
   showed `⏵⏵ auto mode on`, and the next hooks had
   `permission_mode: auto`. After that, the hooks were `PostToolUse` and
   `Stop`.
4. In run 3, the scenario sent "4" ("No"). The command did not run. The
   screen showed `⎿  Interrupted · What should Claude do instead?`. No
   hook fired: no `PostToolUse` and no `Stop`. The next hook was the
   `UserPromptSubmit` of the next prompt. The pid file `status` was
   `idle` at each read, from 1 s after the key. This is the same result
   as Esc in fact 024.
5. The `PermissionRequest` payload of the Bash dialog had two
   `permission_suggestions`: `{"type": "addDirectories", "directories":
   ["/work/example"], "destination": "session"}` and `{"type": "setMode",
   "mode": "acceptEdits", "destination": "session"}`. The screen option
   "3. Yes, and switch to auto mode" has no suggestion in the payload. Its
   `tool_input` keys were `command` and `description` (run 3), or also
   `dangerouslyDisableSandbox`, `run_in_background` and `timeout`
   (run 2). The model sets these keys.

## Mechanism

The digit of "No" depends on the dialog. A tool that sends "3" as "No"
approves a Bash command and turns on auto mode. A tool must read the
digit of the "No" row from the screen, or send Esc. Esc and "No" gave the
same signals.

The number of `permission_suggestions` does not give the number of
options: two suggestions, four options.

## Incident

None. tg-bridge asked which hooks fire after "3. No", and the answer
showed that "3." is "No" only in some dialogs.

## Screens

None.

## Not measured

- "No" with text after Tab ("Tab to amend").
- "2." on the Bash dialog.
- Which commands open no dialog, other than `ls` and `sleep`.
- A Bash dialog in a folder that is not trusted, and in acceptEdits
  mode.
- Other models, macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/034-the-claude-task-folder-keeps-the-first-session.md

# 034. The Claude task folder keeps the first session ID of the process

## Measured

2026-10-30, Claude Code 2.1.314 with `--model haiku`, on Linux (Debian 13,
x64), in a private tmux server with a throwaway `HOME`. The scenario
`scenarios/claude/dialog-states.sh` (three runs) listed the open files of
the process at each step from `/proc/<pid>/fd`, and listed the folders
and files below `/tmp/claude-<uid>/<project key>/`.
Measured on: real machine.

## What was measured

1. After the start, and after a question from the agent, the process held
   no folder below `/tmp/claude-<uid>/` open. Only
   `/tmp/claude-<uid>/<project key>/<session id>/scratchpad` existed.
2. The first Bash tool call made
   `/tmp/claude-<uid>/<project key>/<session id>/tasks`, and the process
   then held it open. In run 2 and run 3 that call was a foreground `ls`,
   not a background task. So a Bash call opens the folder, not only a
   background task.
3. A background task wrote its output to `tasks/<task id>.output`. The
   task ID is the `backgroundTaskId` of the hooks (fact 031).
4. After `/clear`, the pid file and the hooks named the new session ID
   (fact 023, fact 024). The process still held the `tasks` folder of the
   first session ID open. The new session got only a `scratchpad` folder.
5. A background task that started after `/clear` wrote its output to the
   `tasks` folder of the first session ID, not to a folder of the new
   session ID.
6. The folders stay after the process ends. The scenario cleanup deletes
   them.

## Mechanism

The process makes its task folder one time, with the session ID that it
has at that time. `/clear` does not move the folder.

A reader that takes the session ID from the open task folder (fact 025)
gets the first session ID of the process. After `/clear`, that ID is
wrong. It is correct only when the process has had one session. The pid
file (fact 023) gives the current session ID.

## Incident

None.

## Screens

None.

## Not measured

- A session with no Bash call at all after a long time.
- Whether `--resume` in a new process makes a new task folder, or uses
  the folder of the resumed ID.
- `/resume` inside a running process.
- macOS and Windows, where the temporary folder is different.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/035-a-claude-resume-keeps-the-session-and-the-transcript.md

# 035. A Claude resume keeps the session ID and the transcript file

## Measured

2026-10-30, Claude Code 2.1.314 with `--model haiku`, on Linux (Debian 13,
x64), in a private tmux server with a throwaway `HOME`. The scenario
`scenarios/claude/plan-and-resume.sh` ran one session, stopped it with
`/exit`, and started `claude --resume <sessionId>` in a new process. It
listed the files below `~/.claude/sessions/` and `~/.claude/projects/` at
each step, and recorded every hook payload. One run.
Measured on: real machine.

## What was measured

1. After `/exit`, `SessionEnd` fired with `reason: prompt_input_exit`.
   The files `<pid>.json` and `<pid>.<64 hex characters>.key` of the
   first process were gone. The transcript file stayed.
2. The new process had a new pid and wrote a new `<pid>.json` and a new
   `.key` file. Its `sessionId` was the same ID as in the first process.
3. `SessionStart` fired with `source: resume` and the same `session_id`.
   Its `transcript_path` was the same file as in the first process.
4. The new process appended to that transcript file. The file grew at
   the resume and again after the next prompt. No other transcript file
   appeared in the project folder.
5. After the first prompt of the resumed session, the hooks were
   `UserPromptSubmit`, `Stop`, and then `SubagentStop` with an empty
   `agent_type`. The scenario did not start a subagent. The cause of this
   `SubagentStop` is not known.
6. The resumed screen drew the old conversation, and the name of the
   session (`create-note-txt`) in the frame of the input box.

## Mechanism

A session ID names one transcript file for the whole life of the
session, also across processes. A reader that maps a pid to a session
(fact 023) must read the pid file again for each new process. The
session ID can stay the same while the pid changes.

## Incident

None.

## Screens

None.

## Not measured

- `/resume` inside a running process, and `--continue`.
- A resume while the first process still runs.
- A resume after a crash, with a pid file that stayed.
- Whether a resumed process uses the task folder of the resumed ID
  (fact 034). No Bash call ran after the resume.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/036-a-codex-denial-ends-the-turn.md

# 036. A Codex denial ends the turn

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install,
x86_64-unknown-linux-musl), on Linux (Debian 13, x64), in the default
daemon mode with `--sandbox read-only --ask-for-approval on-request`, in a
private tmux server with a throwaway `HOME` and a copied login. The
scenario `scenarios/codex/deny.sh` recorded at each step the screen and
the record types of the rollout file (`type` and `payload.type`, as
`record_types` in `scenarios/lib.sh` gives them). It read no content.
One run with all steps, and one earlier run with the denial only.
Measured on: real machine.

## What was measured

1. A prompt that asked for a file write in the read-only folder opened the
   approval dialog "Would you like to run the following command?" with
   `1. Yes, proceed (y)`, `2. Yes, and don't ask again for commands that
   start with ... (p)` and `3. No, and tell Codex what to do differently
   (esc)`. The `custom_tool_call` record of the command was in the file
   before the dialog opened.
2. The digit `3` acted at once, with no Enter. Codex did not ask for a
   text. 3 s later the screen showed the empty box and the footer
   `? for shortcuts`, with these lines above them:

   ```
   ✗ You canceled the request to run printf 'hello' > note3.txt

   • Exited (status 1) printf 'hello' > note3.txt
     └ (no output)

   ■ Conversation interrupted - use /feedback if something went wrong
   ```

3. The digit `3` added these records, in this order:
   `response_item` `custom_tool_call_output`, `event_msg` `token_count`,
   `response_item` `message`, `event_msg` `turn_aborted`. No record came
   in the next 5 s. The turn ended. It did not go on.
4. Esc on the same dialog gave the same four records and the same lines on
   the screen. Thus a reader cannot tell "3. No" from Esc in the rollout
   file or on the screen.
5. The text that the user typed after the denial started a new turn:
   `event_msg` `thread_settings_applied`, `event_msg` `task_started`,
   `turn_context`, and at its end `event_msg` `task_complete`.
6. The digit `1` (`Yes, proceed`) also acted at once. It gave
   `event_msg` `item_completed`, `response_item` `custom_tool_call_output`,
   `event_msg` `token_count`, `event_msg` `item_completed`,
   `response_item` `message`, `token_usage_record`, `event_msg`
   `token_count` and `event_msg` `task_complete`. The file was written.
7. In the first run, the denial came first. On the next write prompt the
   model refused with no dialog ("I can't create the file because this
   session's workspace is read-only."). The scenario thus asks for the
   denial last.

## Mechanism

"3. No, and tell Codex what to do differently" is the Esc action of the
dialog: its label ends with `(esc)`. Both cancel the command and abort the
turn. The "tell Codex" part is the next prompt of the user, which starts a
new turn.

## Incident

None recorded.

## Screens

`codex/approval-v0-164-0`, `codex/after-deny-v0-164-0`.

## Not measured

- The digit `3` followed by Enter, and the key `n`.
- `2. Yes, and don't ask again`.
- The file-change approval dialog.
- `--no-daemon`. Fact 27 found the same records in both modes for Esc.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/037-codex-ctrl-c-opens-a-task-dialog.md

# 037. Ctrl+C during a Codex turn opens a task dialog

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install,
x86_64-unknown-linux-musl), on Linux (Debian 13, x64), in the default
daemon mode, in a private tmux server with a throwaway `HOME` and a
copied login. The scenario `scenarios/codex/interrupt.sh` recorded at
each step the screen, the record types of the rollout file, and whether
the TUI process ran. It read no content.
Measured on: real machine.

The command was `sleep 20`, approved with the digit `1` on the approval
dialog (`--sandbox read-only --ask-for-approval on-request`). On this
machine `bwrap` cannot make a namespace, so a command in the sandbox fails
at once ("bwrap: No permissions to create a new namespace ..."). With
`--ask-for-approval never`, `sleep 20` thus ended in less than 1 s with
status 1. An approved command runs outside the sandbox.

## What was measured

1. Ctrl+C while the command ran did not stop the turn. It opened this
   dialog in place of the input box, with no busy line and no footer
   `? for shortcuts`:

   ```
     Task is still running
     Choose what happens to the current task.


   › 1. Cancel task        Stop the current task and stay in Codex
     2. Run in background  Exit Codex and leave the task running
     3. Exit               Stop the current task and exit Codex

     enter select · esc back
   ```

   The dialog added no record to the rollout file.
2. The answers to the dialog. A digit acted at once, with no Enter.

   | Key | Screen | Records added | TUI |
   |---|---|---|---|
   | `1` (Cancel task) | `• Exited (status 1) sleep 20`, `■ Conversation interrupted - use /feedback if something went wrong`, the empty box | `custom_tool_call_output`, `token_count`, `message`, `turn_aborted` | runs |
   | Esc (back) | the busy line `• Working (7s • esc to interrupt)` is back; the command ends (`• Ran sleep 20`) and the turn ends normally | at the end: `task_complete` | runs |
   | `3` (Exit) | no pane: the TUI exited | `custom_tool_call_output`, `token_count`, `message`, `turn_aborted` | exited |

3. Esc while the command ran (no dialog) gave the same screen and the same
   four records as `1. Cancel task`, then one `event_msg` `item_completed`
   within 6 s. The TUI kept running.
4. In an earlier run of the scenario, Ctrl+C came while the model wrote a
   long answer with no tool. The same dialog opened. The turn went on
   behind the dialog: the rollout file got `task_complete` and the `Stop`
   hook fired, and the dialog stayed open. Then the digit `2` of a typed
   prompt ("sleep 20") answered the dialog with `2. Run in background`,
   and the TUI exited.
5. Two Ctrl+C, 1 s apart, on an idle box exited the TUI in
   `scenarios/codex/deny.sh` and in the second run of
   `scenarios/codex/daemon-life.sh`. In the first run of
   `daemon-life.sh`, the same keys left two of three TUIs running.

## Mechanism

Each interrupt that stops the turn writes `turn_aborted`: Esc during a
command, `1. Cancel task`, `3. Exit`, and the denial of fact 36. A reader
of the rollout file sees the end of the turn in each case.

A reader of the screen must know the dialog of item 1. It hides the busy
line and the idle footer. A tool that types a prompt into it can answer it
by mistake, because a digit acts at once (fact 4), and `2` exits the TUI.

## Incident

The first version of the interrupt scenario typed a prompt with the digit
`2` into this dialog. The TUI exited, and the scenario lost its pane.

## Screens

`codex/task-running-v0-164-0`.

## Not measured

- Why two Ctrl+C on an idle box did not exit two of the TUIs in one run.
- What `2. Run in background` leaves running, and which records follow.
- Ctrl+C during a sandboxed command, on a machine where `bwrap` works.
- `--no-daemon`.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/038-the-codex-hooks.md

# 038. The Codex hooks

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install,
x86_64-unknown-linux-musl), on Linux (Debian 13, x64), in the default
daemon mode, in a private tmux server with a throwaway `HOME` and a
copied login. `codex features list` and `strings` on the binary gave the
feature and the event names. The scenarios `scenarios/codex/deny.sh` and
`scenarios/codex/interrupt.sh` wrote `~/.codex/hooks.json` with one
command hook for each event (`codex_hooks` in `scenarios/lib.sh`). Each
hook wrote the time, the event and the sorted top-level keys of its
payload to a log. It wrote no values. Four runs.
Measured on: real machine.

## What was measured

1. `codex features list` shows `hooks  stable  true`. The binary holds
   these event names: `SessionStart`, `SessionEnd`, `UserPromptSubmit`,
   `PreModelRequest`, `PreToolUse`, `PermissionRequest`, `PostToolUse`,
   `PreCompact`, `PostCompact`, `SubagentStart`, `SubagentStop`,
   `Interrupt` and `Stop`. The file
   `{"hooks": {"<event>": [{"hooks": [{"type": "command", "command": "...", "timeout": 10}]}]}}`
   in `~/.codex/hooks.json` loaded all 13. The hooks list showed the
   source "User config - ~/.codex/hooks.json".
2. New hooks do not run until the user trusts them. The first start
   showed this dialog before the input box:

   ```
     Hooks need review
     13 hooks are new or changed.
     Hooks can run outside the sandbox after you trust them.

   › 1. Review hooks
     2. Trust all and continue
     3. Continue without trusting (hooks won't run)

     enter confirm · esc skip
   ```

   Here a digit only moves the selection; Enter confirms it. The trust
   wrote `~/.codex/config.toml` (42 bytes before, 2653 bytes after).
   Codex warned: "clamping SessionEnd hook timeout to 3s" and "clamping
   Interrupt hook timeout to 3s".
3. The payload keys of each event that fired:

   | Event | Keys |
   |---|---|
   | `SessionStart` | `cwd hook_event_name model permission_mode session_id source transcript_path` |
   | `UserPromptSubmit` | `cwd hook_event_name model permission_mode prompt session_id transcript_path turn_id` |
   | `PreModelRequest` | `cwd hook_event_name model session_id transcript_path turn_id` |
   | `PreToolUse` | `cwd hook_event_name model permission_mode session_id tool_input tool_name tool_use_id transcript_path turn_id` |
   | `PermissionRequest` | `cwd hook_event_name model permission_mode session_id tool_input tool_name transcript_path turn_id` |
   | `PostToolUse` | `cwd hook_event_name model permission_mode session_id tool_input tool_name tool_response tool_use_id transcript_path turn_id` |
   | `Interrupt` | `cwd hook_event_name model permission_mode session_id transcript_path turn_id` |
   | `Stop` | `cwd hook_event_name last_assistant_message model permission_mode session_id stop_hook_active transcript_path turn_id` |
   | `SessionEnd` | `cwd hook_event_name reason session_id transcript_path` |

   `PreCompact`, `PostCompact`, `SubagentStart` and `SubagentStop` did
   not fire. The scenarios did not cause a compaction or a subagent.
4. The hooks that fired, in order:

   | Step | Hooks |
   |---|---|
   | The TUI starts | none |
   | The first prompt | `SessionStart`, `UserPromptSubmit`, `PreModelRequest` |
   | Each later prompt | `UserPromptSubmit`, `PreModelRequest` |
   | A normal turn with no tool ends | `Stop` |
   | The approval dialog opens | `PreToolUse`, `PermissionRequest` |
   | `1. Yes, proceed` on a file write | `PostToolUse`, `PreModelRequest`, then `Stop` at the end |
   | `3. No` on the dialog | `Interrupt` |
   | Esc on the dialog | `Interrupt` |
   | Esc while an approved command runs | `Interrupt` |
   | Ctrl+C, then `1. Cancel task` or `3. Exit` | `Interrupt` |
   | Ctrl+C, then Esc on the task dialog; the turn ends | `PreModelRequest`, `Stop` |
   | The TUI exits | `SessionEnd` |

5. `Stop` did not fire after `3. No`, after Esc, or after any interrupt
   that wrote `turn_aborted` (facts 36 and 37). `Interrupt` fired in each
   of these cases, and in no other case.
6. `PostToolUse` did not fire for an approved `sleep 20`, also when it
   ended normally. It fired for an approved `printf` and for a command
   that failed in the sandbox.

## Mechanism

The `Interrupt` hook is the hook signal for an aborted turn. A tool that
waits for `Stop` after Esc or a denial waits for ever. A tool that also
listens to `Interrupt` sees the end of each turn of these runs: `Stop` or
`Interrupt`. Both payloads have `turn_id`.

`PermissionRequest` gives the tool and its input, not the labels of the
dialog.

## Incident

tg-bridge measured that the Stop hook does not fire after Esc or after the
digit 3. These runs confirm it, and show the `Interrupt` hook in its
place.

## Screens

None.

## Not measured

- Whether `SessionEnd` comes from the exit of the TUI or from the stop of
  the daemon: in most runs both happened within 1 s.
- The hook output: a hook that blocks, or that returns JSON.
- A `matcher`, and hooks in a project `.codex/` folder.
- `PreCompact`, `PostCompact`, `SubagentStart`, `SubagentStop`.
- The payload values, and the environment of the hook process.
- `--no-daemon`, and which process runs the hooks.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/039-the-codex-daemon-outlives-its-tuis-and-updates-itself.md

# 039. The Codex daemon outlives its TUIs and updates itself

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install,
x86_64-unknown-linux-musl), on Linux (Debian 13, x64), in a private tmux
server with a throwaway `HOME` and a copied login. The scenario
`scenarios/codex/daemon-life.sh` ran two TUIs in the default daemon mode,
then a `--no-daemon` TUI next to them, then a third daemon-mode TUI after
the first ones exited. It read `/proc/<pid>/fd` of each process and the
command line of the daemon, and logged the daemon each 10 s for 300 s
after the last TUI exited. Two runs. The update of item 5 has a time only
in the second run.
Measured on: real machine.

## What was measured

1. Two TUIs with the same `HOME` used one app-server daemon, as in fact 26.
   The daemon held the rollout file and the lock of both sessions.
2. A `codex --no-daemon` TUI that started next to the running daemon held
   its own rollout file and its own lock
   (`~/.codex/thread-writer-locks/<session id>.lock`). The daemon did not
   hold them. The daemon pid did not change.
3. After the TUIs exited, the daemon kept running, with parent pid 1. A TUI
   that started 30 s later used the same daemon pid. No second daemon
   started. The daemon then held the lock and the rollout file of the new
   session too.
4. The daemon did not exit in the 300 s after the last TUI exited, in
   either run.
5. The daemon replaced itself with a newer version. In the second run,
   between 203 s and 213 s after the last TUI exited (about 6 minutes
   after the daemon started):
   - The daemon of 0.164.0 stopped.
   - `~/.codex/packages/app-server-daemon/releases/0.166.0-x86_64-unknown-linux-musl/`
     appeared, and a daemon from that folder started with a new pid.
   - The `pid-update-loop` process kept its pid, but its command line now
     named the 0.166.0 folder. It became the parent of the new daemon.
   - The new daemon held no rollout file and no lock of the ended
     sessions.
   In the first run, the same change happened between 0 s and 304 s after
   the last TUI exited. The installed `codex` stayed 0.164.0, and each TUI
   drew "Update available! 0.164.0 -> 0.166.0".

## Mechanism

The daemon has its own release folder below `~/.codex/packages/`, apart
from the installed CLI. The `pid-update-loop` process updates it with no
TUI. Thus the daemon can run a newer version than the TUI, and the pid of
the daemon is not stable while it runs.

## Incident

None recorded. A reader that keeps the daemon pid, or that reads the
version of the daemon from its path, can be wrong after an update.

## Screens

None.

## Not measured

- When the daemon exits, if ever.
- What starts the update: the age of the daemon, a timer, or the end of
  the last TUI. Whether it also happens while a TUI runs.
- Whether a TUI of 0.164.0 can use the daemon of 0.166.0.
- A machine with no newer version to download.
- Two Ctrl+C left two TUIs running in the first run (fact 37). The
  hangup of the tmux server ended them.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/040-the-codex-databases-hold-no-tui-link.md

# 040. The Codex databases hold no link from a TUI to its thread

## Measured

2026-10-30, Codex CLI 0.164.0 (standalone install,
x86_64-unknown-linux-musl), on Linux (Debian 13, x64), in the default
daemon mode, in a private tmux server with a throwaway `HOME` and a
copied login. The scenario `scenarios/codex/daemon-life.sh` read the
table layout of each `~/.codex/*.sqlite` file while two TUIs ran, with
`sqlite3 -readonly` and only `.tables` and `.schema`. It read no row. It
also read `/proc/<pid>/fd` of each process. Two runs gave the same
layout. The file list of `scenarios/codex/deny.sh` gave the names and
sizes below `~/.codex`.
Measured on: real machine.

## What was measured

1. `~/.codex` holds six SQLite files, each in WAL mode (with `-wal` and
   `-shm` files): `state_5.sqlite`, `logs_2.sqlite`,
   `thread_history_1.sqlite`, `goals_1.sqlite`, `memories_1.sqlite` and
   `queue_1.sqlite`.
2. The tables of `state_5.sqlite`: `threads`, `thread_attachments`,
   `thread_dynamic_tools`, `thread_read_receipts`, `thread_sections`,
   `thread_spawn_edges`, `projects`, `project_roots`,
   `project_idempotency_keys`, `backfill_state`,
   `rollout_migration_state`, `rollout_migration_skipped_rollouts`,
   `external_agent_config_imports`, `guardian_review_feedback`,
   `remote_control_enrollments` and `_sqlx_migrations`.
3. No column of `state_5.sqlite` holds a pid, a tty, a pane or a client of
   the daemon. `threads` has `id`, `rollout_path`, `cwd`, `source`,
   `originator`, `cli_version`, `created_at` and `updated_at`, and more.
   `thread_read_receipts` has `thread_id`, `first_unread_turn`,
   `revision` and `last_published_turn`: one row for each thread, not for
   each client. `remote_control_enrollments` has `app_server_client_name`,
   for remote control.
4. `logs_2.sqlite` has one table `logs` with the columns `thread_id` and
   `process_uuid`, and an index on `process_uuid` for rows with no thread.
   This is the only layout that joins a process to a thread. The
   `process_uuid` is not a pid, and no table maps it to a pid.
5. The other tables: `thread_history_1.sqlite` has `thread_items`,
   `thread_turns`, `thread_realtime_items` and
   `thread_history_projection_state`. `goals_1.sqlite` has `thread_goals`
   and `thread_goal_continuation_deferrals`. `queue_1.sqlite` has
   `queued_items` and `queued_thread_revisions`. `memories_1.sqlite` has
   `jobs`, `stage1_outputs` and `consolidation_progress`.
6. Each daemon-mode TUI holds `state_5`, `logs_2`, `goals_1`, `memories_1`
   and `queue_1` open, but not `thread_history_1`. The daemon and the
   `--no-daemon` TUI hold all six. Thus the open databases of a TUI do not
   name its thread.
7. Codex makes an empty file (0 bytes)
   `~/.codex/tui-thread-reference-capabilities/<session id>` when a
   session starts, before the first prompt. Two daemon-mode TUIs and one
   `--no-daemon` TUI left two such files; a third daemon-mode TUI added
   one more. No process held one open, while a TUI ran or after.

## Mechanism

The daemon keeps the threads. The tables describe threads, not the
clients that show them. A reader that must link a daemon-mode TUI to its
thread finds no pid in these layouts.

## Incident

None recorded. aw asked for an exact link from a Codex TUI to its thread
in daemon mode (fact 26).

## Screens

None.

## Not measured

- The rows. A row of `logs` could hold a `process_uuid` of a TUI, and the
  text of a log line could name a pid. Neither was read.
- The content of the files below `tui-thread-reference-capabilities/`
  other than their size, and which process makes them.
- The app-server protocol on the daemon socket, which could list clients.
- `codex agents`, which browses the sessions of the daemon.
- macOS and Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/041-an-agy-deny-fires-no-end-hook.md

# 041. An agy deny on the file dialog fires no end hook

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64), in a
private tmux server with a throwaway `HOME` and a copied login. The
scenario `scenarios/agy/deny-and-tools.sh` ran two times. It set a hook
for each of the six events in `~/.gemini/config/hooks.json`, and recorded
at each step the screen, the hook payloads, and the type, the keys and the
enum values of each transcript record. It read no conversation text.
Measured on: real machine.

## What was measured

1. The prompt asked for a file write. The file dialog "Allow creation of
   this file?" opened. The scenario sent the digit `2` ("No, deny
   creation"). The file was not written.
2. The hooks of that turn, in both runs:

   | Step | Hooks |
   |---|---|
   | The prompt | `SessionStart` (first prompt only), then `PreInvocation` |
   | Before the dialog draws | `PreToolUse` (fact 42) |
   | `2` on the dialog | none |
   | The next prompt | `PreInvocation` |

   `PostToolUse`, `PostInvocation` and `Stop` did not fire for the denied
   turn. No `Stop` payload with `terminationReason` `USER_CANCELED` or
   any other value came.
3. The screen after the deny shows `⎿  User declined the tool call` and
   `⎿  Interrupted · What should Antigravity CLI do instead?`, then a framed,
   empty box and `? for shortcuts`. The next prompt ran. After that prompt,
   the history keeps only the "User declined the tool call" line.
4. The deny added one record to `transcript.jsonl`, of type `GENERIC`, in
   both runs. The second run also recorded the keys: that record has
   `status` `ERROR` and an `error` key. A tool call that ran added a
   `GENERIC` record with `status` `DONE` and no `error` key.
5. Esc on the same dialog (turn 4 of each run) gave the same hooks as in
   item 2, and added no transcript record. The screen shows
   `⎿  Interrupted · What should Antigravity CLI do instead?`.
6. The tool-call record (`PLANNER_RESPONSE` with a `tool_calls` key) is in
   the transcript before the dialog draws. It is the last record while the
   dialog waits, and after an Esc.
7. Each transcript record has the keys `content` (not in a tool-call
   record), `created_at`, `source`, `status`, `step_index` and `type`.

## Mechanism

agy ends a denied turn and an Esc turn without its normal end path, so it
calls neither `PostInvocation` nor `Stop`. A reader that waits for `Stop`
after a deny waits for ever, as after an Esc (fact 28). The summaries
database shows the end of these turns (fact 45). The screen shows it too.

A reader of the transcript can tell a deny from an Esc: a deny adds a
`GENERIC` record with `status` `ERROR`, and an Esc adds no record.

## Incident

None recorded.

## Screens

`agy/file-permission-v1-4-7`, `agy/after-deny-v1-4-7`,
`agy/after-escape-v1-4-7`.

## Not measured

- The text of the `error` value. The scenario reads no content.
- A deny of a command dialog ("Run this command?").
- "No" with a text from the operator (`tab Amend`).
- macOS and Windows. Other agy versions.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/042-the-agy-tool-hooks-need-a-matcher-group.md

# 042. The agy tool hooks need a matcher group

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64). The
hook shape comes from the documentation text in the agy binary
(`strings -n 6` on the installed binary, the section "Lifecycle Hooks
(`hooks.json`)"). The scenario `scenarios/agy/deny-and-tools.sh` ran two
times in a private tmux server with a throwaway `HOME` and a copied login,
with hooks in `~/.gemini/config/hooks.json`. Each hook printed nothing.
The first run used an earlier copy of the script, with a different list of
tool names in the third matcher (item 2).
Measured on: real machine.

## What was measured

1. The documentation in the binary says that `PreToolUse` and
   `PostToolUse` take a group with a `matcher` regex and a `hooks` list.
   The other four events take a flat list of handlers. The shape is:

   ```json
   {"<name>": {"PreToolUse": [{"matcher": "*", "hooks": [{"type": "command", "command": "...", "timeout": 10}]}]}}
   ```

2. With this shape, `PreToolUse` and `PostToolUse` fired. The matchers
   `"*"` and `""` fired in both runs. The matcher `"write_file|read_file"`
   fired in the second run (the first run did not have it). The matchers
   `"write_to_file|view_file|run_command|code_action|list_dir"` (first run)
   and `"write_to_file|view_file|code_action|list_dir"` (second run) did
   not fire. In fact 28, the flat shape with no group did not fire.
3. The tool names were `write_file` (the file write) and `read_file` (a
   file read).
4. The payload keys:

   | Event | Keys |
   |---|---|
   | `PreToolUse` | `artifactDirectoryPath`, `conversationId`, `lastUserInput`, `modelName`, `stepIdx`, `toolCall`, `transcriptPath`, `workspacePaths` |
   | `PostToolUse` | the keys of `PreToolUse`, and `error` (empty for a tool that ran) |

   `toolCall` has `name` and `args`. The `args` keys of `write_file` were
   `Content`, `Overwrite` and `Path`. The `args` key of `read_file` was
   `Path`. The hook process had `ANTIGRAVITY_CONVERSATION_ID` in its
   environment.
5. The order of the hooks:

   | Turn | Hooks |
   |---|---|
   | A read with no dialog | `PreInvocation`, `PreToolUse`, `PostToolUse` (about 0.1 s later), `PostInvocation`, `PreInvocation`, `PostInvocation`, `Stop` |
   | A write, "1" on the dialog | `PreInvocation`, `PreToolUse` (before the dialog draws), `PostToolUse` (after the answer), `PostInvocation`, `PreInvocation`, `PostInvocation`, `Stop` |
   | A write, "2" or Esc on the dialog | `PreInvocation`, `PreToolUse`, then nothing (fact 41) |

6. A hook that printed nothing did not change the dialog. The dialog drew,
   and the read ran with no dialog.
7. `Stop` came with `terminationReason` `NO_TOOL_CALL` and `fullyIdle`
   `true` for each turn that ended normally.

## Mechanism

The documentation in the binary says that a `PreToolUse` hook can print a
`decision` (`allow`, `deny`, `ask`, `force_ask`). An observer must print
nothing, or `ask`, so that it does not answer the dialog for the operator.
The scenario measured only "nothing".

`PreToolUse` with no `PostToolUse` means that a tool runs or that a dialog
waits. The hooks do not tell these two apart. The screen does.

## Incident

None recorded.

## Screens

`agy/file-permission-v1-4-7`.

## Not measured

- A hook that prints a `decision`.
- Other tools: a shell command (`run_command` in the documentation), a
  web search, an MCP tool.
- A matcher that is not a valid regex.
- `.agents/hooks.json` in the work folder, and hooks in a plugin.
- macOS and Windows. Other agy versions.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/043-agy-continue-reuses-the-conversation-files.md

# 043. agy --continue reuses the files of the conversation

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64), in a
private tmux server with a throwaway `HOME` and a copied login. The
scenario `scenarios/agy/continue.sh` started agy four times in the same
`HOME` and work folder: `agy` with no prompt, `agy --continue` with no
conversation, `agy --continue`, and `agy --conversation <id>`. Each start
after the first had one short turn. It recorded the hooks, the open files,
the kernel locks, the file list and the transcript record types.
Measured on: real machine.

## What was measured

1. `agy --continue` in a folder with no conversation drew the same bytes
   as a new start: the normal idle box and `? for shortcuts`. It held no
   `presence` or `conversations` file open. The first prompt made a new
   conversation, and `SessionStart` fired.
2. `agy --continue` with one conversation, and `agy --conversation <id>`,
   used the same conversation ID. The new process opened the same files:
   - `~/.gemini/antigravity-cli/presence/<conversation id>.lock`;
   - `~/.gemini/antigravity-cli/conversations/<conversation id>.db`, with
     its `-wal` and `-shm` files.
   It opened them at the start, before the first prompt. A new session
   opens them at the first prompt (fact 28).
3. `SessionStart` did not fire for a continued conversation. Each turn gave
   `PreInvocation`, `PostInvocation` and `Stop`, with the same
   `conversationId`.
4. The folder held one `.db` file after the three turns. The `.lock` file
   kept its first modification time. After each exit, the `-wal` and `-shm`
   files were gone, and the `.db` file was larger.
5. A continued turn added a `SYSTEM_MESSAGE` record after its `USER_INPUT`
   record in `transcript.jsonl`. The first turn had no `SYSTEM_MESSAGE`
   record.
6. The screen of a continued session shows the earlier turns above the
   box.

## Mechanism

A reader that links a process to its conversation by the names of the open
files (fact 28) gets the same ID for a continued process. Such a reader
must not wait for `SessionStart` to learn the ID: a continued process
sends none. It can read the ID from the open files at the start, or from
`conversationId` in `PreInvocation`.

## Incident

tg-bridge noted that agy 1.4.7 `--continue` in an empty folder draws an
empty framed box that reads as idle (fact 28). This measurement shows that
the box is idle: the same screen as a new start, and the next prompt ran.

## Screens

`agy/continue-empty-v1-4-7`.

## Not measured

- `--continue` in a folder with two or more conversations, and from a
  subfolder.
- `--conversation` with an ID that does not exist.
- Two processes on one conversation at the same time.
- The text of the `SYSTEM_MESSAGE` record.
- macOS and Windows. Other agy versions.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/044-the-agy-presence-file-is-a-flock-lock.md

# 044. The agy presence file is a flock lock

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64), in a
private tmux server with a throwaway `HOME` and a copied login. The
scenarios `scenarios/agy/deny-and-tools.sh` (two runs) and
`scenarios/agy/continue.sh` (one run, three processes) ran, at each step,
`flock -n <file> true` on each file in
`~/.gemini/antigravity-cli/presence/`, from another process. They also
listed the lines of `/proc/locks` for the inode of each file in
`presence/` and `conversations/`. Both only read.
Measured on: real machine.

## What was measured

1. While agy ran, `flock -n` on `presence/<conversation id>.lock` exited
   with 1: another process held the lock. `/proc/locks` showed one
   `FLOCK ADVISORY WRITE` lock on the file. This was so at each step:
   busy, a dialog, after a turn, and after an Esc.
2. After the process exited, `flock -n` exited with 0, and `/proc/locks`
   showed no lock. The file stayed, with size 0.
3. A new session made the file and took the lock at the first prompt.
   Before the first prompt, `presence/` had no file. A process started with
   `--continue` or `--conversation <id>` took the lock at the start
   (fact 43).
4. `conversations/<conversation id>.db` and its `-shm` file each had one
   `POSIX ADVISORY READ` lock while agy ran. The `-wal` file had none.

## Mechanism

agy takes an exclusive `flock` lock on the presence file and keeps it until
the process exits. The kernel drops the lock when the process ends, also
after a crash. A reader can test whether a conversation is open in a live
process with `flock -n <file> true`: exit 1 means open. The test changes
nothing, and it needs no process list. The file alone does not show this:
it stays after the exit.

The `POSIX` read locks on the `.db` and `-shm` files are the locks of
SQLite in WAL mode.

## Incident

None recorded.

## Screens

None.

## Not measured

- A crash or a `kill -9` of agy.
- Two processes on one conversation at the same time.
- The lock on macOS (`flock` is not installed there by default) and on
  Windows.
- A lock file on a network file system.
- Other agy versions.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/045-the-agy-summaries-database-shows-a-running-turn.md

# 045. The agy summaries database shows a running turn

## Measured

2026-10-30, Antigravity CLI (agy) 1.4.7, on Linux (Debian 13, x64), in a
private tmux server with a throwaway `HOME` and a copied login. The
scenario `scenarios/agy/deny-and-tools.sh` ran two times, with four turns
in each run. A poller listed every 0.5 s the size and the modification
time of each file below `~/.gemini/antigravity-cli/`. In the second run,
each time `conversation_summaries.db` changed, the poller copied it (with
its `-wal` and `-shm` files) and read `status`, `not_fully_idle` and
`step_count` from the copy. It read no conversation text.
Measured on: real machine.

## What was measured

1. `~/.gemini/antigravity-cli/conversation_summaries.db` is a SQLite file
   with one table, `conversation_summaries`, and one row for each
   conversation. Its columns include `conversation_id`, `status`,
   `not_fully_idle`, `step_count`, `killed`, `last_modified_time` and
   `last_user_input_time`.
2. The `status` of the row in the second run:

   | Time (s) | Event | `status`, `not_fully_idle` |
   |---|---|---|
   | 0.3 | turn 1 sent | |
   | 2.2 | | `CASCADE_RUN_STATUS_RUNNING`, 1 |
   | 5.8 | the file dialog opens | |
   | 8.2 | the dialog waits | `CASCADE_RUN_STATUS_RUNNING`, 1 |
   | about 10.0 | `2` (deny) sent | |
   | 10.8 | | `CASCADE_RUN_STATUS_IDLE`, 0 |
   | 28.3 | `Stop` of turn 2 | |
   | 28.8 | | `CASCADE_RUN_STATUS_IDLE`, 0 |
   | 64.7 | `Stop` of turn 3 | |
   | 65.0 | | `CASCADE_RUN_STATUS_IDLE`, 0 |
   | about 81.0 | Esc on the dialog of turn 4 | |
   | 83.1 | | `CASCADE_RUN_STATUS_IDLE`, 0 |

   Each turn changed the status to `CASCADE_RUN_STATUS_RUNNING` within
   2.2 s of the prompt. The status stayed `RUNNING` while a dialog waited.
   It changed to `CASCADE_RUN_STATUS_IDLE` within 0.5 s of `Stop`, within
   0.8 s of a deny, and within 2.1 s of an Esc. No hook fires for the deny
   and the Esc (fact 41).
3. `~/.gemini/antigravity-cli/jetbox_summaries_proto.pb` changed at the same
   times as `conversation_summaries.db-wal`.
4. The conversation files changed only at the steps of a turn:
   `conversations/<conversation id>.db-wal` and the four transcript files
   below `brain/<conversation id>/.system_generated/logs/`
   (`transcript.jsonl`, `transcript_full.jsonl`, and one file in each of
   `chunks/transcript/` and `chunks/transcript_full/`). In turn 3 of the
   second run, no conversation file changed for 21.6 s while the turn ran.
   A size or a modification time of these files does not show that a turn
   runs.
5. `history.jsonl` changed at each prompt that was sent. `cli.log` and the
   file in `log/` changed during the turns and also at other times.

## Mechanism

agy keeps the run state of each conversation in the summaries database,
apart from the transcript. A reader with no hooks can read the `status` of
the row with its `conversation_id`. `RUNNING` means busy or a dialog. The
screen tells these two apart (fact 18). `IDLE` also shows the end of a deny
and of an Esc, where no hook fires.

A reader must not hold a lock on the live database. The scenario read a
copy. A read-only connection to the live file was not tested.

## Incident

None recorded.

## Screens

`agy/busy-v1-4-7`.

## Not measured

- Other values of `status`, for example for an error or a crash.
  `killed` was 0 in each read.
- The content of `jetbox_summaries_proto.pb`.
- The status in the first run (the poller did not read it then).
- The delay with a poll faster than 0.5 s.
- A read-only connection to the live database.
- macOS and Windows. Other agy versions.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/046-the-first-start-of-ten-more-agents.md

# 046. The first start of ten more agents with no login

## Measured

2026-10-30, the scenario `scenarios/first-run.sh <agent> <command>` in the
scenarios workflow (run 41137353062, and again in run 41138908257), with a
throwaway `HOME`, no login and no key. The workflow installed each agent on
the runner:

| Agent | Command | Version | Install |
|---|---|---|---|
| Amp | `amp` | 0.0.1793390435-g08e9ec | npm `@ampcode/cli` |
| Goose | `goose` | 1.57.0 | `download_cli.sh` of the `block/goose` release `stable`, with `CONFIGURE=false` |
| Crush | `crush` | v0.99.0 | npm `@charmland/crush` |
| Kimi Code CLI | `kimi` | 2.4.1 | `curl -fsSL https://code.kimi.com/kimi-code/install.sh \| bash` |
| Continue CLI | `cn` | 1.5.47 | npm `@continuedev/cli` |
| Factory Droid | `droid` | 1.0.0 | npm `@factory/cli` |
| Cline CLI | `cline` | 3.0.74 | npm `cline` |
| Kilo Code CLI | `kilo` | 7.8.18 | npm `@kilocode/cli` |
| Auggie | `auggie` | 0.36.0 | npm `@augmentcode/auggie` |
| OpenHands CLI | `openhands` | 1.16.0 | `uv tool install --python 3.12 openhands` |

Node.js was 22.23.4 (from `actions/setup-node`) on each runner. In run
41137353062, the first line of `openhands --version` was a Python warning
on stderr ("AuthlibDeprecationWarning"). Run 41138908257 took the line
from stdout: "OpenHands CLI 1.16.0".

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64). Each agent installed and started on each of these
runners. Fact 50 gives the differences between Linux and macOS.

## What was measured

The screen after 20 s, the processes, the files below the throwaway `HOME`,
and the files that the processes held open. The paths below are relative
to `HOME`.

1. Amp asks on a plain line: "No API key found. Starting login flow..."
   and "Would you like to log in to Amp? [(y)es, (n)o]:". It runs as one
   native process `amp`. It holds `.cache/amp/logs/cli.log` open and makes
   `.local/share/amp/`.
2. Goose starts its setup at once: "Welcome to goose! Let's get you set
   up." and "Share anonymous usage data to help improve goose?" with
   "● Yes / ○ No". It runs as one process `goose`. It holds
   `.local/state/goose/logs/cli/<date>/<date>_<time>.log` open and makes
   `.local/share/goose/`.
3. Crush shows "To start, let's choose a provider and model." with a
   search field "> Find your fave" and a list of models. It runs as
   `node .../bin/crush` with a native child
   `.../@charmland/crush/bin/crush`. It makes three files in
   `.local/share/crush/` and holds none open.
4. Kimi Code CLI asks "Trust this folder?" with "❯ Trust and continue"
   and "Exit". It runs as one native process `kimi`. It makes
   `.kimi-code/` (`config.toml`, `tui.toml`, `device_id`,
   `workspaces.json`, `updates/latest.json`, `updates/rollout.log`,
   `cache/client-configs`) and a cache of native modules.
5. Continue CLI asks on a plain line: "To get started, enter your Anthropic
   API key." and "Enter your Anthropic API key:". It runs as
   `node .../bin/cn`. It holds `.continue/logs/cn.log` open.
6. Factory Droid draws a full screen with "Welcome to Factory CLI", "Please
   login with your Factory account to continue." and a menu "> Login",
   "Sign into a Factory Private deployment", "Exit". It runs as one native
   process `droid`. It makes `.factory/` with `settings.json`, `host.json`,
   `state/`, `cache/`, `droids/`, `telemetry/droid-installation-id` and
   `bin/script-runtime-<hex>`. It held no file open.
7. Cline CLI shows "Welcome to Cline", "Connect a model provider to get
   started." and four boxes: "Sign in with Cline", "Sign in with
   ClinePass", "Sign in with ChatGPT" and "Bring your own provider". It
   runs as `node .../bin/cline`, a native child `.../cline/bin/.cline`, and
   a third process `.cline --cline-hub-daemon --cwd <folder>` with no tty.
   The processes hold SQLite files in `.cline/data/db/` open (`sessions.db`,
   `tasks.db`, `teams.db`, `cron.db`, `session-search.db`,
   `hub-events-hub-production.db`, `hub-runs-hub-production.db`, each with
   `-wal` and `-shm`), `.cline/data/locks/hub/production.json.instance.lock`
   and two logs in `.cline/data/logs/`.
8. Kilo Code CLI shows its input box "Ask anything..." with "Code · Auto
   Free Kilo Gateway" and no login prompt. It runs as `node .../bin/kilo`
   with a native child `.../@kilocode/cli/bin/.kilo`. It holds
   `.local/share/kilo/kilo.db` (with `-wal` and `-shm`) and logs in
   `.local/share/kilo/log/` open, one of them `opencode.log`. It makes
   `.config/kilo/kilo.jsonc` and `.cache/kilo/models.json`.
9. Auggie shows "New to Augment? You can create an account from the login
   page.", "→ Login to continue" and "Press return to open your browser".
   It runs as `node .../bin/auggie`. It makes `.augment/.auggie.json` and
   `.augment/oauth-state.json`, and holds no file open.
10. OpenHands CLI shows a "Settings" form with "Settings Mode: Basic",
    "LLM Provider: Select" and "LLM Model: Select". It runs as the Python
    of its uv tool folder with `~/.local/bin/openhands`. It made no file
    below `HOME` in 20 s.

## Mechanism

Kilo Code CLI writes a log named `opencode.log` and keeps a SQLite file
`kilo.db` in the place where opencode keeps `opencode.db` (fact 29). This
suggests a fork of opencode. A reader that knows opencode can look for the
same layout. The source of Kilo Code was not read.

Cline CLI starts a daemon (`--cline-hub-daemon`) with no tty before a
login, as the Codex app-server does after a login (fact 26). A reader that
maps a process to a terminal must skip that daemon.

Only Kilo Code CLI starts in its input box. The other nine agents first
show a login, a key prompt, a provider choice, a trust question, or a
setup step.

## Incident

None.

## Screens

None. The screens are in the logs of the runs, not in the corpus.

## Not measured

- The screens after a login, and any turn.
- Whether the Cline daemon stays after the TUI stops.
- Kimi Code CLI, Goose and OpenHands CLI on Windows.
- Agents that the workflow does not install: Kiro CLI, and the Python
  Kimi CLI (`kimi-cli` on PyPI), which its page marks as archived.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/047-where-windows-installs-keep-their-version.md

# 047. Where the Windows installs keep their version

## Measured

2026-10-30, the scenario `scenarios/windows-installs.ps1` in the scenarios
workflow (run 41137353062, and again in run 41138908257). The workflow
installed each agent, then the scenario ran `Get-Command <cmd> -All` and
`<cmd> --version`, read `package.json`, and listed the install folder. It
started no agent interactively.

| Agent | Command | Version | Install |
|---|---|---|---|
| Claude Code | `claude` | 2.1.314 | npm `@anthropic-ai/claude-code` |
| Codex CLI | `codex` | 0.166.0 | npm `@openai/codex` |
| opencode | `opencode` | 1.19.5 | npm `opencode-ai` |
| Gemini CLI | `gemini` | 0.66.0 | npm `@google/gemini-cli` |
| GitHub Copilot CLI | `copilot` | 1.0.105 | npm `@github/copilot` |
| Qwen Code | `qwen` | 0.26.4 | npm `@qwen-code/qwen-code` |
| Amp | `amp` | 0.0.1793390435-g08e9ec | npm `@ampcode/cli` |
| Crush | `crush` | v0.99.0 | npm `@charmland/crush` |
| Continue CLI | `cn` | 1.5.47 | npm `@continuedev/cli` |
| Factory Droid | `droid` | 1.0.0 | npm `@factory/cli` |
| Cline CLI | `cline` | 3.0.74 | npm `cline` |
| Kilo Code CLI | `kilo` | 7.8.18 | npm `@kilocode/cli` |
| Auggie | `auggie` | 0.36.0 | npm `@augmentcode/auggie` |
| Cursor CLI | `agent`, `cursor-agent` | 2026.10.22-27dcf5f | `irm 'https://cursor.com/install?win32=true' \| iex` |
| Kimi Code CLI | `kimi` | 2.4.1 | `irm https://code.kimi.com/kimi-code/install.ps1 \| iex` |

Node.js 22.23.4 and npm 10.9.9 (from `actions/setup-node`).

Measured on: CI runner windows-2022 (Windows NT 10.0.20348, x64), CI
runner windows-2025 (10.0.26100, x64) and CI runner windows-11-arm
(10.0.26200, arm64). The two x64 images gave the same layout. Fact 48
gives the arm64 differences.

## What was measured

1. The npm prefix on all three images is `C:\npm\prefix`. For each npm
   agent, npm writes three shims there: `<cmd>.ps1`, `<cmd>.cmd` and
   `<cmd>` with no extension. `Get-Command <cmd> -All` lists them in this
   order: `ExternalScript <cmd>.ps1`, `Application <cmd>.cmd`,
   `Application <cmd>`. None of the npm paths holds the version. The
   version is in `C:\npm\prefix\node_modules\<package>\package.json`, and
   on the x64 images it was the same as `--version` for each npm agent.
2. The shims point to one of three kinds of target:
   - A native `.exe` in the main package: Claude Code
     (`@anthropic-ai\claude-code\bin\claude.exe`), opencode
     (`opencode-ai\bin\opencode.exe`) and Amp (`@ampcode\cli\bin\amp.exe`).
     The same file is also in a platform package, for example
     `@anthropic-ai\claude-code-win32-x64\claude.exe`,
     `opencode-windows-x64\bin\opencode.exe` and
     `opencode-windows-x64-baseline\bin\opencode.exe`.
   - A JavaScript launcher that starts a native `.exe` from a platform
     package: Codex CLI (`bin\codex.js` to
     `@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe`,
     next to `codex-code-mode-host.exe`, `codex-path\rg.exe` and
     `codex-resources\codex-command-runner.exe`), Copilot CLI
     (`npm-loader.js` to `@github\copilot-win32-x64\copilot.exe`), Crush
     (`run-crush.js` to `@charmland\crush\bin\crush.exe`), Factory Droid
     (`bin\droid` to `@factory\cli-win32-x64\bin\droid.exe`), Cline CLI
     (`bin\cline` to `@cline\cli-windows-x64\bin\cline.exe`) and Kilo
     Code CLI (`bin\kilo` to `@kilocode\cli-windows-x64\bin\kilo.exe`).
   - JavaScript that runs in `node.exe`: Gemini CLI
     (`bundle\gemini.js`), Qwen Code (`cli-entry.js`), Continue CLI
     (`dist\cn.js`) and Auggie (`augment.mjs`).
3. The file version of a native `.exe` is not the agent version.
   `copilot.exe` had 1.0.105 and `claude.exe` had 2.1.314.0 (run
   41138908257), the agent versions. `opencode.exe`,
   `amp.exe`, `droid.exe` and `kilo.exe` all had 1.4.4. `cline.exe` had
   1.4.2. `codex.exe` and `crush.exe` had no file version.
4. Cursor CLI installs to `%LOCALAPPDATA%\cursor-agent`, and the installer
   adds that folder to the user `PATH`. The folder holds `agent.cmd`,
   `agent.ps1`, `cursor-agent.cmd` and `cursor-agent.ps1`, and
   `versions\<version>\` with `node.exe`, `rg.exe`, `crepectl.exe`,
   `cursorsandbox.exe`, `node_sqlite3.node`, `node_modules\` and a `.running\`
   folder. `versions\promote-staged.cmd` is next to the version
   folders. The version is the name of the folder
   `versions\2026.10.22-27dcf5f`, the same as `--version`.
5. Kimi Code CLI installs one file, `%USERPROFILE%\.kimi-code\bin\kimi.exe`,
   and a file `region` in `.kimi-code`. No path holds the version. Only
   `kimi --version` gave it.
6. `--version` makes files for some agents. After the calls, these
   folders were new: `.codex`, `.cursor`, `.gemini`,
   `%LOCALAPPDATA%\copilot` and `%LOCALAPPDATA%\cursor-compile-cache` (the
   first group of agents), and `.cline`, `.continue`, `.cache`, `.config`,
   `.local`, `%LOCALAPPDATA%\amp` and `%LOCALAPPDATA%\kimi-code` (the second
   group).

## Mechanism

A tool that wants the version of a running agent on Windows can read it
from the path only for Cursor CLI. For an npm agent, it can go from the
process image (for example `codex.exe` in a platform package) up to the
`node_modules\<package>` folder of the main package and read
`package.json`. For Gemini CLI, Qwen Code, Continue CLI and Auggie, the
process image is `node.exe`, so the tool must read the command line of the
process to find the package.

## Incident

None. This answers request 13 of aw (where the Windows installs keep their
version).

## Screens

None. The output is in the logs of the runs.

## Not measured

- The process tree of a running agent on Windows: the scenario starts no
  agent interactively.
- The standalone Windows installer of Codex CLI, and installs with
  `winget`, Scoop or Chocolatey.
- Which agent of the second group made `.cache`, `.config` and `.local`.
- The Goose and OpenHands CLI installs on Windows.
- An npm prefix other than `C:\npm\prefix`, for example the default
  `%APPDATA%\npm` of a new Node.js install.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/048-windows-arm64-installs.md

# 048. The agent installs on Windows arm64

## Measured

2026-10-30, the scenario `scenarios/windows-installs.ps1` in the scenarios
workflow (run 41137353062, and again in run 41138908257), with the same
agents, versions and install commands as in fact 47. Node.js 22.23.4 for
arm64.

Measured on: CI runner windows-11-arm (Windows NT 10.0.26200, arm64),
compared with CI runner windows-2022 and windows-2025 (x64).

## What was measured

1. Amp does not run on Windows arm64. npm installed `@ampcode/cli` with
   no error, but `bin\amp.exe` was a file of 141 bytes, and
   `amp --version` printed "This version of
   C:\npm\prefix\node_modules\@ampcode\cli\bin\amp.exe is not compatible
   with the version of Windows you're running." and exited with 1. On x64,
   `bin\amp.exe` was 134,019,408 bytes and gave the version. The npm
   registry lists these platform packages of `@ampcode/cli`:
   `linux-x64`, `linux-arm64`, `darwin-x64`, `darwin-arm64` and
   `win32-x64`. There is no `win32-arm64` package.
2. Each other agent of fact 47 installed and gave its version on arm64.
   These agents use a native arm64 package:
   - Claude Code: `@anthropic-ai\claude-code-win32-arm64\claude.exe`.
   - Codex CLI: `@openai\codex-win32-arm64\vendor\aarch64-pc-windows-msvc\bin\codex.exe`.
   - opencode: `opencode-windows-arm64\bin\opencode.exe`. There is no
     `baseline` package on arm64.
   - Copilot CLI: `@github\copilot-win32-arm64\copilot.exe`.
   - Factory Droid: `@factory\cli-win32-arm64\bin\droid.exe`.
   - Cline CLI: `@cline\cli-windows-arm64\bin\cline.exe`.
   - Kilo Code CLI: `@kilocode\cli-windows-arm64\bin\kilo.exe`. There is
     no `baseline` package on arm64.
   - Cursor CLI: `versions\<version>\file_service.win32-arm64-msvc.node`
     and `merkle-tree-napi.win32-arm64-msvc.node`.
3. Qwen Code on arm64 has `vendor\ripgrep\x64-win32\rg.exe`, an x64
   binary, and no arm64 `rg.exe`. Its native modules for the terminal and
   the clipboard are arm64 (`@lydell\node-pty-win32-arm64`,
   `@teddyzhu\clipboard-win32-arm64-msvc`).
4. The `.exe` files of opencode, Amp (x64), Factory Droid and Kilo Code CLI
   have the file version 1.4.4, and `cline.exe` has 1.4.2, on both CPU
   types. The npm registry has `@oven/bun-*` packages with the version
   1.4.4 (an optional dependency of Qwen Code).

## Mechanism

An npm package with a native binary can install on a platform that it has
no binary for, and fail only when it starts. A tool that sees the command
on `PATH` must not take that as a working install.

The file version 1.4.4 is probably the version of Bun, if these
executables are made with Bun. This was not checked in the binaries.

## Incident

None.

## Screens

None. The output is in the logs of the runs.

## Not measured

- Whether Amp has another install for Windows arm64 (for example an x64
  binary under emulation).
- Whether Qwen Code can search files on arm64 with the x64 `rg.exe`.
- The process tree of a running agent on Windows arm64.
- Goose, OpenHands CLI and Aider on Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/049-the-free-runner-images.md

# 049. The free GitHub-hosted runner images for the probes and scenarios

## Measured

2026-10-30, the probes workflow (run 41137356489, and the pull request run
41138261939) and the scenarios workflow (run 41137353062). The probes
workflow ran each Unix probe, the Windows probes and the kit with no agent
installed. Its step "Image" printed `uname -srm`, the OS name and the path
of `ps`, `pgrep`, `lsof`, `tmux`, `sudo` and `python3`. The scenarios
workflow ran `scenarios/first-run.sh` for 18 agents (facts 29, 30 and 46)
and `scenarios/windows-installs.ps1` for 15 agents (fact 47).

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04,
ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm, ubuntu-slim,
macos-15, macos-26, macos-15-intel, macos-26-intel, windows-2022,
windows-2025 and windows-11-arm.

## What was measured

1. Each label started a job, and each probe passed its section check on
   each label.
2. The images:

   | Label | OS | Kernel | CPU | `tmux` | `lsof` |
   |---|---|---|---|---|---|
   | ubuntu-22.04 | Ubuntu 22.04.5 LTS | 6.8.0-1070-azure | x86_64 | yes | yes |
   | ubuntu-22.04-arm | Ubuntu 22.04.5 LTS | 6.8.0-1070-azure | aarch64 | yes | yes |
   | ubuntu-24.04 | Ubuntu 24.04.5 LTS | 7.0.0-1017-azure | x86_64 | yes | yes |
   | ubuntu-24.04-arm | Ubuntu 24.04.5 LTS | 7.0.0-1017-azure | aarch64 | yes | yes |
   | ubuntu-26.04 | Ubuntu 26.04.1 LTS | 7.0.0-1017-azure | x86_64 | yes | yes |
   | ubuntu-26.04-arm | Ubuntu 26.04.1 LTS | 7.0.0-1017-azure | aarch64 | yes | yes |
   | ubuntu-slim | Ubuntu 24.04.5 LTS | 6.1.158.2-microsoft-standard | x86_64 | no | no |
   | macos-15 | macOS 15.8.2 (24H232) | Darwin 24.6.0 | arm64 | no | yes |
   | macos-15-intel | macOS 15.7.9 (24G830) | Darwin 24.6.0 | x86_64 | no | yes |
   | macos-26 | macOS 26.6.2 (25G83) | Darwin 25.6.0 | arm64 | no | yes |
   | macos-26-intel | macOS 26.6.1 (25G76) | Darwin 25.6.0 | x86_64 | no | yes |
   | windows-2022 | Windows NT 10.0.20348 | | x64 | | |
   | windows-2025 | Windows NT 10.0.26100 | | x64 | | |
   | windows-11-arm | Windows NT 10.0.26200 | | arm64 | | |

   `sudo`, `ps`, `pgrep` and `python3` were present on each Linux and macOS
   image, also on ubuntu-slim.
3. On ubuntu-slim, all seven Unix probes passed with no `lsof` and no
   `tmux`. On Linux, the probes read open files from `/proc`.
4. Each of the 18 agents installed and started on each of the ten Linux and
   macOS labels, with the same version on each label. Each agent showed the
   same first prompt on each label, with one exception: on
   ubuntu-26.04-arm, Aider first asked "Allow collection of anonymous
   analytics to help improve aider? (Y)es/(N)o [Yes]:", and did not make
   `.aider/caches/versioncheck`. On the other nine labels it first asked
   "No git repo found, create one to track aider's changes
   (recommended)?" (as in fact 30).
5. Aider: `pipx install aider-chat` worked on ubuntu-22.04 and ubuntu-24.04
   (both CPU types). It failed on ubuntu-26.04 (both CPU types) and on the
   four macOS labels with "Fatal error from uv prevented installation". On
   macos-15, the failed build of `tiktoken` ran in a `python3.15` folder.
   `uv tool install --python 3.12 aider-chat` then installed Aider 0.86.2
   on each of these labels.
6. The jobs took 3.8 to 5.6 minutes on Linux, 5.8 to 11.1 minutes on macOS
   (the Intel images were the slowest) and 3.4 to 7.0 minutes on Windows,
   for 8 to 10 agents in one job.
7. The scrub (`tools/scrub.sh`, `tools/scrub.ps1`) reads each run of four
   numbers with dots as an IPv4 address. It changed the ubuntu-slim kernel
   version in the probe header to `os: linux <ip>-microsoft-standard`, and
   the four-part file version of `claude.exe` on Windows to `<ip>`.
   `scenarios/windows-installs.ps1` now prints the four parts with spaces
   (run 41138908257).

## Mechanism

The free images differ in the tools that a scenario needs. A scenario that
needs `tmux` must install it on macOS. A probe that needs `lsof` on Linux
fails on ubuntu-slim, so the Linux probes use `/proc`.

Aider asked the analytics question on one label only, with the same
version and the same install. The choice is probably random for each new
install. The source of Aider was not read.

The Python of the newer images is too new for some Python agents. A fixed
Python (3.12 through uv) makes the install the same on each image.

## Incident

None.

## Screens

None.

## Not measured

- The number of CPUs and the memory of each image.
- The Python version of each image, except the `python3.15` folder on
  macos-15.
- The scenarios on ubuntu-slim: the workflow does not run them there.
- The images with more CPUs (`-large`, `-xlarge`), the preview images, and
  macos-14.
- Whether the first screens stay the same on these images with a login.

## Later change (2026-10-30)

The scrub (`tools/scrub.sh`, `tools/scrub.ps1`) now keeps a dotted quad that
comes after `v` or `version`, or before a letter, `-` or `+`. Thus the
kernel version and the file versions above stay as they are. The text above
describes the scrub before this change.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/050-linux-and-macos-differ-in-cache-folders-and-open-files.md

# 050. Linux and macOS differ in the cache folders and the open files of agents

## Measured

2026-10-30, the scenario `scenarios/first-run.sh <agent> <command>` in the
scenarios workflow (run 41137353062), with a throwaway `HOME`, no login and
no key. The agents and versions are in facts 29, 30 and 46. The scenario
lists the open files of the agent processes with `open_files` from
`probes/lib.sh`: on Linux it reads `/proc/<pid>/fd`, on macOS it runs
`lsof -n -P -p <pid>`.

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64). The three Linux versions gave the same files. The
four macOS images gave the same files, except the CPU name in the paths.

## What was measured

The paths are relative to `HOME`.

1. GitHub Copilot CLI 1.0.105 keeps its native package in a cache folder
   whose path holds the version:
   - Linux: `.cache/copilot/pkg/linux-<cpu>/1.0.105/`. The process holds
     `inuse.<pid>.hold` in that folder open.
   - macOS: `Library/Caches/copilot/pkg/darwin-<cpu>/1.0.105/`. The open
     files are `inuse.<pid>.hold` and, in `prebuilds/darwin-<cpu>/`,
     `cli-native.node`, `runtime.node`, `msal-node-runtime.node` and
     `libmsalruntime_<cpu>.dylib`.
   On both, `<cpu>` is `x64` or `arm64`, and the process also holds
   `.copilot/session-state/<session id>/inuse.<pid>.hold` and
   `.copilot/logs/process-<milliseconds>-<pid>.log` open.
2. Kimi Code CLI 2.4.1 keeps a cache of native modules in
   `.cache/kimi-code/native/` on Linux and in
   `Library/Caches/kimi-code/native/2.4.1/darwin-<cpu>/<hex>/` on macOS.
   On macOS, the process holds `.kimi-code/config.toml`,
   `.kimi-code/workspaces.json` and a `clipboard.darwin-<cpu>.node` file
   from that cache open. On Linux, no file below `HOME` was open.
3. Qwen Code 0.26.4 holds `.qwen/settings.json`, `model-registry.json`,
   `installation_id`, `output-language.md`, `tip_history.json` and
   `extension-store/state.json` open on macOS. On Linux, no file below
   `HOME` was open, on each of the six Linux labels. Fact 30 says that
   Qwen Code holds such files open on both runners. This run shows them
   on macOS only.
4. Kilo Code CLI 7.8.18 also makes `.local/state/kilo/` and
   `.cache/kilo/.metadata_never_index` on macOS. On Linux, these two do not
   exist.
5. These agents use the same folders on Linux and macOS, also the XDG
   folders below `HOME` on macOS: Amp (`.cache/amp`, `.local/share/amp`),
   Goose (`.local/share/goose`, `.local/state/goose`), Crush
   (`.local/share/crush`), Kilo Code CLI (`.local/share/kilo`,
   `.config/kilo`), Cline CLI, Continue CLI, Factory Droid, Auggie,
   Claude Code, Cursor CLI and Gemini CLI. Codex CLI and opencode were not
   compared: the number of files that they make changes from run to run.
6. The scrub changes a path below `~` that is not hidden to
   `/work/example`. On macOS, `actions/setup-node` puts Node.js below
   `~/hostedtoolcache`, so the scrubbed process lines show
   `node /work/example` in place of the path of the agent script. On Linux,
   the path is `/opt/hostedtoolcache/...`, and the scrub keeps it.

## Mechanism

`lsof` on macOS lists the files that a process maps into memory (for
example `.node` and `.dylib` files) and the files that it watches through
kqueue. `/proc/<pid>/fd` on Linux lists only open file descriptors. A file
watch on Linux uses inotify, which holds no descriptor for the file. This
is the probable cause of items 2 and 3: the agent watches its settings
files. It was not checked with a trace.

A tool that finds an agent by its open files must expect fewer files on
Linux than on macOS. The `inuse.<pid>.hold` files of Copilot CLI appear on
both, so they are a stable link from a process to its session (fact 30)
and to its version.

## Incident

None.

## Screens

None. The output is in the log of the run.

## Not measured

- A trace of the system calls, to confirm the file watch.
- The open files on Windows.
- Whether Copilot CLI removes the old version folder after an update.
- The open files after a login, when more files exist.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/051-the-windows-process-trees-in-a-pseudo-console.md

# 051. The Windows process trees of the agents in a pseudo console

## Measured

2026-10-30, the scenario `scenarios/first-run-windows.py <agent> <command>`
in the scenarios workflow (run 41146500448, and again in run 41145363320).
The driver `scenarios/conpty.py` started each agent in a pseudo console of
120 x 40 with pywinpty 3.1.2 and a throwaway profile, and sent no key. After
5 s and after 20 s it listed each process below the driver with psutil
7.2.2. The workflow installed the agents with
`scenarios/install-windows-agents.ps1`, the same commands and versions as in
fact 47 (Claude Code 2.1.314, Codex CLI 0.166.0, opencode 1.19.5, Gemini CLI
0.66.0, Copilot CLI 1.0.105, Qwen Code 0.26.4, Cursor CLI 2026.10.22-27dcf5f,
Amp 0.0.1793390435-g08e9ec, Crush v0.99.0, Continue CLI 1.5.47, Factory
Droid 1.0.0, Cline CLI 3.0.74, Kilo Code CLI 7.8.18, Auggie 0.36.0, Kimi
Code CLI 2.4.1). Node.js 22.23.4. Python 3.12.16 from uv, for the CPU of
the image.

Measured on: CI runner windows-2022 (Windows NT 10.0.20348, x64), CI
runner windows-2025 (10.0.26100, x64) and CI runner windows-11-arm
(10.0.26200, arm64).

## What was measured

1. The console host is `OpenConsole.exe` from the pywinpty wheel, not the
   `conhost.exe` of Windows:
   `<venv>\Lib\site-packages\winpty\OpenConsole.exe --headless --width 120
   --height 40 --signal 0x<n>`. It is a child of the driver, next to the
   agent, not a child of the agent. It was the same on the three images.
2. The driver starts an npm shim as `cmd.exe /d /c C:\npm\prefix\<cmd>.cmd`,
   as cmd.exe finds the command with PATHEXT. It starts an `.exe` directly.
   Below `cmd.exe`, the trees after 20 s were:

   | Agent | Processes below `cmd.exe` |
   |---|---|
   | Claude Code | `claude.exe` (from `@anthropic-ai\claude-code\bin\`) |
   | Codex CLI | `node codex.js`, then `codex.exe` from `@openai\codex-win32-<cpu>\vendor\<target>\bin\` |
   | opencode | `opencode.exe` |
   | Gemini CLI | `node gemini.js`, then `node.exe --max-old-space-size=8189 gemini.js`, then `powershell.exe -NoProfile -NoLogo -InputFormat Text -NoExit -ExecutionPolicy Unrestricted -C ...`, then `conhost.exe 0x4` |
   | Copilot CLI | `node npm-loader.js`, then `copilot.exe`, then two processes that stopped before psutil read them |
   | Qwen Code | three `node.exe` processes, one below the other |
   | Cursor CLI | `powershell.exe -NoProfile -ExecutionPolicy Bypass -File %LOCALAPPDATA%\cursor-agent\...`, then `versions\<version>\node.exe` |
   | Amp | `amp.exe` (x64 only) |
   | Crush | `node`, then `crush.exe` |
   | Continue CLI | `node` |
   | Factory Droid | `node bin\droid`, then `droid.exe` (run 41145363320) |
   | Cline CLI | `node bin\cline`, then `cline.exe`, then `cline.exe --cline-hub-daemon --cwd <work folder> --host ...` |
   | Kilo Code CLI | `node bin\kilo`, then `kilo.exe` |
   | Auggie | `node` |
   | Kimi Code CLI | no `cmd.exe`: `kimi.exe` is a child of the driver |

3. On windows-11-arm, opencode (run 41146500448) and Kilo Code CLI (run
   41145363320) had a child `choco list --limit-output <name>`, with a
   second `choco.exe` and a `conhost.exe 0x4` below it. The x64 images did
   not show this process at 5 s or at 20 s.
4. Gemini CLI starts a PowerShell with `-NoExit`, which stays after 20 s.
   That PowerShell gets its own `conhost.exe`, outside the pseudo console.
5. No agent left a process with the throwaway folder in its command line
   or folder outside the tree below the driver.
6. Factory Droid 1.0.0 ran in run 41145363320. In run 41146500448, npm
   installed `@factory/cli` with exit 0, but `droid` printed "Error: Could
   not find the droid binary for win32-x64." (and win32-arm64), and
   exited with 1. The npm registry gives 2026-10-30T23:47:30Z as the
   release time of `@factory/cli` 1.1.0, a few minutes before that install.

## Mechanism

The pywinpty wheel holds `conpty.dll` and `OpenConsole.exe` from the
ConPTY package of Microsoft, and its ConPTY backend uses them (the build
script `build.rs` of pywinpty 3.1.2). Windows Terminal also uses its own
OpenConsole. A tool that looks for the terminal of an agent process on
Windows must look at the parent side of the agent, not at its children.

The `choco list` call is probably an update check that asks which package
manager installed the agent. This was not checked in the source.

## Incident

pyte 0.8.2 raised a TypeError on `CSI ? 6 n` (Copilot CLI, Kimi Code CLI)
and on `CSI > ... m` or `CSI ? ... m` (Gemini CLI, Crush), and dropped the
rest of the output chunk (run 41145363320). The driver now ignores these
forms. Run 41146500448 had no parse error.

## Screens

None. The screens and process lists are in the logs of the runs.

## Not measured

- Windows Terminal, conhost.exe and PowerShell as the shell of a real
  user. A user in PowerShell starts `<cmd>.ps1`, not `<cmd>.cmd`.
- The two short-lived children of `copilot.exe`.
- Whether the Gemini CLI PowerShell stays after the agent stops.
- Goose, OpenHands CLI and Aider on Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/052-the-first-screens-on-windows.md

# 052. The first screens on Windows match the Linux screens

## Measured

2026-10-30, the scenario `scenarios/first-run-windows.py` in the scenarios
workflow (run 41146500448, and again in run 41145363320), with the agents
and versions of fact 51, a pseudo console of 120 x 40, a throwaway
profile, no login and no key. The screen after 20 s was compared with the
Linux screens of facts 29, 30 and 46.

Measured on: CI runner windows-2022 (x64), CI runner windows-2025 (x64) and
CI runner windows-11-arm (arm64).

## What was measured

1. These agents showed the same first question as on Linux, with the same
   words and options, on the three images:
   - Claude Code 2.1.314: "Welcome to Claude Code v2.1.314", "Let's get
     started." and "Choose the text style that looks best with your
     terminal", with "> √   Dark mode" selected (fact 29).
   - Codex CLI 0.166.0: "Choose how you want to use Codex." with "1. Sign in
     with ChatGPT" to "4. Use Amazon Bedrock" (fact 29).
   - Cursor CLI: "Cursor Agent", "v2026.10.22-27dcf5f" and "Press any key to
     log in..." (fact 29).
   - Copilot CLI 1.0.105: "Confirm folder trust" with "❯ 1. Yes", "2. Yes,
     and remember this folder for future sessions" and "3. No (Esc)"
     (fact 30).
   - Gemini CLI 0.66.0: "Do you trust the files in this folder?" with
     "● 1. Trust folder (example)", "2. Trust parent folder (work)" and
     "3. Don't trust" (fact 30).
   - Amp: "No API key found. Starting login flow..." and "Would you like to
     log in to Amp? [(y)es, (n)o]:" (x64 only, fact 46).
   - Crush: "To start, let's choose a provider and model." and
     "> Find your fave" (fact 46).
   - Kimi Code CLI 2.4.1: "Trust this folder?" with "❯ Trust and continue"
     and "Exit" (fact 46).
   - Continue CLI 1.5.47: "To get started, enter your Anthropic API key."
     (fact 46).
   - Factory Droid 1.0.0: "Welcome to Factory CLI", "Please login with your
     Factory account to continue." and "> Login" (run 41145363320, fact 46).
   - Cline CLI 3.0.74: "Welcome to Cline", "Connect a model provider to get
     started." and four boxes from "Sign in with Cline" to "Bring your own
     provider" (fact 46).
   - Kilo Code CLI 7.8.18: the input box "Ask anything..." and "Code  · Auto
     Free Kilo Gateway" (fact 46).
   - Auggie 0.36.0: "New to Augment? You can create an account from the
     login page." and "→ Login to continue" (fact 46).
   - opencode 1.19.5: the input box "Ask anything…" and "/update to upgrade
     to OpenCode 2.0" (fact 29).
2. Qwen Code 0.26.4 showed a box "Connect a Provider" with "› QwenCloud"
   and "Alibaba ModelStudio". Fact 30 gives other words ("Choose a built-in
   provider and connect with an API key"). The Linux version of fact 30 was
   not compared.
3. Differences between the Windows images:
   - On windows-2022 only, Gemini CLI added "⚠  Warning: Windows 10
     detected. Some UI features like smooth scrolling may be degraded.
     Windows 11 is recommended for ...". Windows Server 2022 has the build
     number 20348.
   - Kimi Code CLI, Kilo Code CLI and opencode show the work folder as a
     Windows path, for example `D:\a\_temp\run.<id>\work\example` on x64
     and `C:\a\_temp\...` on arm64.
   - On windows-11-arm, Amp printed "This version of
     C:\npm\prefix\node_modules\@ampcode\cli\bin\amp.exe is not compatible
     with the version of Windows you're running." and exited (fact 48).

## Mechanism

These agents draw with the same code on Windows and on Linux. ConPTY
sends the screen as VT output, which the driver reads as tmux reads a pane.
A reader of the screens of facts 29, 30 and 46 can read the Windows screens
too, with these exceptions: Windows paths in the screen, and the Gemini
warning on Windows Server 2022.

## Incident

None.

## Screens

None. The screens are in the logs of the runs, not in the corpus.

## Not measured

- The styles (colors) of the screens. The driver gives plain text only.
- The screens after a key, a login or a turn.
- Windows Terminal or conhost.exe as the terminal. ConPTY can render
  differently in another host.
- Whether the Gemini warning shows on Windows 10 desktop builds.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/053-codex-on-windows-ignores-userprofile.md

# 053. Codex CLI on Windows ignores USERPROFILE and HOME

## Measured

2026-10-30, the scenario `scenarios/first-run-windows.py codex codex` in
the scenarios workflow (run 41146500448, and again in run 41145363320),
Codex CLI 0.166.0 from npm `@openai/codex`. The driver set USERPROFILE,
HOME, HOMEDRIVE, HOMEPATH, APPDATA, LOCALAPPDATA, TEMP and TMP to folders
in a throwaway folder for the agent. It listed the real profile folders
(USERPROFILE and APPDATA to two levels, LOCALAPPDATA to two levels without
`Temp`, and TEMP to one level) before the start, and again after 5 s and
after 20 s.

Measured on: CI runner windows-2022 (x64), CI runner windows-2025 (x64) and
CI runner windows-11-arm (arm64).

## What was measured

1. Codex CLI made no file in the throwaway home on the three images.
2. On the three images, Codex CLI made these entries in the real
   `%USERPROFILE%\.codex` after 5 s, and they were the same after 20 s:
   `config.toml`, `installation_id`, `version.json`, `.sandbox`, `.tmp`,
   `skills`, and the SQLite files `state_5`, `logs_2`, `goals_1`,
   `memories_1` and `queue_1`, each with `-wal` and `-shm`. These are the
   same names as in `~/.codex` on Linux (fact 29).
3. Its screen was the normal first screen (fact 52). The processes were
   `node codex.js` and `codex.exe` (fact 51).
4. Each other agent of fact 51 that started made its own files in the
   throwaway home. Amp on windows-11-arm and Factory Droid in run
   41146500448 did not start (fact 51).

## Mechanism

`codex.exe` is a Rust program. A Rust program that asks Windows for the
profile folder (for example with `SHGetKnownFolderPath`) does not read
USERPROFILE or HOME. This was not checked in the source. `CODEX_HOME` was
not set. Codex CLI has the variable `CODEX_HOME` for the folder of
`~/.codex`. It was not tested here.

A scenario on Windows that must not touch the real profile must set
`CODEX_HOME` for Codex CLI. A tool that looks for the Codex files of a
Windows user must look in the profile folder of the account, not in a
folder from the environment of the process.

## Incident

The first-run scenario wrote a Codex state into the real profile of each
runner. The runner is thrown away after the job, so this did no harm in CI.
On a real machine, the same scenario would add files to the user's
`.codex` folder.

## Screens

None.

## Not measured

- Whether `CODEX_HOME` moves all these files on Windows.
- Whether Codex CLI on Windows reads a login from the real `.codex` when
  USERPROFILE points elsewhere.
- Codex CLI on Linux or macOS with HOME changed: there, the first-run
  scenario found the files in the throwaway HOME (fact 29).
- The standalone Windows installer of Codex CLI.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/054-cursor-cli-on-windows-uses-the-account-name-of-windows.md

# 054. Cursor CLI on Windows uses the account name of Windows and its install folder

## Measured

2026-10-30, the scenario `scenarios/first-run-windows.py cursor
cursor-agent` in the scenarios workflow (run 41146500448, and again in run
41145363320), Cursor CLI 2026.10.22-27dcf5f from
`irm 'https://cursor.com/install?win32=true' | iex`. The driver set the
throwaway profile of fact 53 and USERNAME=dev. It logged each file path
below the throwaway home that held the real account name, and the changes
in the real profile folders.

Measured on: CI runner windows-2022 (x64), CI runner windows-2025 (x64) and
CI runner windows-11-arm (arm64).

## What was measured

1. Cursor CLI made `.cursor\agent-cli-state.json`, `cli-config.json` and
   `statsig-cache.json` in the throwaway home, the same files as on Linux
   (fact 29). It reads USERPROFILE for these.
2. It made a log
   `AppData\Local\Temp\cursor-agent-logs-<account>\session-<time>-<pid>-1.log`
   in the throwaway TEMP, and held it open. `<account>` was the account name
   of Windows, not the USERNAME value `dev`. The driver logged "2 paths
   below the throwaway home hold the Windows account name" at 5 s and at
   20 s on the three images (run 41146500448).
3. In the real profile, the folder `%LOCALAPPDATA%\cursor-agent\versions`
   changed on the three images. This is the install folder. The `.cmd`
   shim starts `powershell.exe -NoProfile -ExecutionPolicy Bypass -File`
   with a script in that folder, and the script starts
   `versions\<version>\node.exe` (fact 51).
4. In run 41145363320, the real `%USERPROFILE%\.cursor` also changed on
   windows-2025 and windows-11-arm. In run 41146500448, it did not change.

## Mechanism

The shim finds the install from its own path, not from LOCALAPPDATA, so
the agent starts also when LOCALAPPDATA points elsewhere. The account name
probably comes from `os.userInfo()` of Node.js, which asks Windows and not
the environment. This was not checked in the source.

The `.cursor` change in run 41145363320 can come from the `--version` call,
which ran with the real profile before the start. This was not checked.

A tool that wants the log folder of a Cursor CLI session on Windows must
use the account name of the process, not USERNAME.

## Incident

The account name of the runner showed in a CI log of an earlier run of
this scenario (run 41144210399, now deleted). The scrub did not find it,
because a `-` before the name is a word character for the scrub's account
rule. The driver now replaces the account name in each file that it
writes.

## Screens

None.

## Not measured

- Whether the `.running` folder below `versions\` holds a file for each
  running session.
- Cursor CLI started from PowerShell with `cursor-agent.ps1`.
- The `agent` command, which the installer also adds.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/055-the-real-profile-changes-with-no-agent-on-windows-runners.md

# 055. The real profile of a Windows runner changes with no agent action

## Measured

2026-10-30, the scenario `scenarios/first-run-windows.py` in the scenarios
workflow (run 41146500448, and again in run 41145363320), with the 15
agents of fact 51. For each agent, the driver listed the real profile
folders before the start and after 20 s (fact 53), and wrote the new,
changed and removed entries to `02-after-20s.outside`.

Measured on: CI runner windows-2022 (x64), CI runner windows-2025 (x64) and
CI runner windows-11-arm (arm64).

## What was measured

1. Only Codex CLI (fact 53) and Cursor CLI (fact 54) made a change in the
   real profile that their own files explain.
2. The other changes have no link to the files of the agent, and they came
   for different agents in the two runs:
   - `%USERPROFILE%\ntuser.dat.LOG1` and `ntuser.dat.LOG2`, the registry
     log of the profile (an earlier run of the scenario; the driver now
     skips them).
   - `%USERPROFILE%\_bazel_<account>` (windows-2022: Claude Code and Amp).
   - `%LOCALAPPDATA%\Temp` (Auggie and Kilo Code CLI on the three images,
     Cursor CLI on windows-2025 and windows-11-arm). The driver gives the
     agent another TEMP.
   - `%LOCALAPPDATA%\D3DSCache` and `%LOCALAPPDATA%\Microsoft` (windows-2025:
     Claude Code, Amp), and `%LOCALAPPDATA%\Microsoft\Credentials`
     (windows-2022: Amp).
   - New `%APPDATA%\Mozilla\Firefox` and `%LOCALAPPDATA%\Mozilla\Firefox`
     (windows-2025: Claude Code in run 41145363320, Continue CLI and Factory
     Droid in the runs).
   - `%LOCALAPPDATA%\Packages` (windows-11-arm: Codex CLI, in both runs).
   - `%USERPROFILE%\.kimi-code` (windows-2025: Amp in run 41145363320). The
     Kimi Code CLI install had put `kimi.exe` there before the run.
3. Each of these changes was a folder entry: a changed folder time or a
   new folder. The driver lists only two levels, so it did not list the
   files in these folders.

## Mechanism

A Windows runner has services that write to the profile of the runner
account while a job runs: the registry, the graphics shader cache, a
Firefox profile, the credential store and the Bazel cache folder. The
driver cannot tell which process made a change. A change that comes for
different agents in different runs is not an agent signal.

A test of "which agents ignore USERPROFILE" on Windows must look for the
agent's own file names in the real profile, not for any change.

## Incident

None.

## Screens

None.

## Not measured

- Which process made each of these changes. The driver did not trace file
  writes (for example with Process Monitor or ETW).
- Changes deeper than two levels below the real profile folders, other
  than below `.codex`.
- A second run of each agent on the same runner.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/056-gemini-warns-about-colors-on-ubuntu-22-04.md

# 056. Gemini CLI warns about limited colors on ubuntu-22.04

## Measured

2026-10-30, Gemini CLI 0.66.0 (npm `@google/gemini-cli`), the scenario
`scenarios/first-run.sh gemini gemini` in the scenarios workflow (run
41142220844), with a throwaway `HOME`, no login and no key. The scenario
starts the agent in a private tmux server with `tmux -f /dev/null`, so tmux
uses its default settings. The workflow uploaded the scrubbed screen after
20 s of each label as an artifact.

Measured on: CI runner ubuntu-22.04 (x64), ubuntu-22.04-arm (arm64),
ubuntu-24.04, ubuntu-26.04 (x64), ubuntu-24.04-arm, ubuntu-26.04-arm
(arm64), macos-15, macos-26 (arm64), macos-15-intel and macos-26-intel
(x64).

## What was measured

1. On ubuntu-22.04 and ubuntu-22.04-arm, Gemini CLI printed four more lines
   above its folder-trust dialog:

   ```
   ⚠  Warning: Limited color support detected (TERM=screen). Some visual elements may not render correctly. For better
      color support in tmux, add to ~/.tmux.conf:
            set -g default-terminal "tmux-256color"
            set -ga terminal-overrides ",*256col*:Tc"
   ```

2. On the other eight labels, Gemini CLI printed no such warning. The rest of
   the screen was the same on all ten labels: the dialog "Do you trust the
   files in this folder?" with the same three options.
3. The warning moves the dialog down by six lines. The question, the options
   and the selected mark do not change.

## Mechanism

The warning names `TERM=screen`. Gemini CLI reads the terminal type, and on
the two ubuntu-22.04 images it found a type with limited colors. The tmux of
an image sets `TERM` in the pane from its `default-terminal` option. The
tmux version and the `TERM` value of the other images were not recorded, so
the cause of the difference is not proved.

A reader that finds the trust dialog by its line number fails on
ubuntu-22.04. A reader that finds it by its text works on all ten labels.

## Incident

None.

## Screens

- `gemini/trust-v0-66-0` (ubuntu-24.04, no warning)
- `gemini/trust-color-warning-v0-66-0` (ubuntu-22.04, with the warning)

## Not measured

- The tmux version and the value of `TERM` in the pane on each image.
- Whether the warning goes away with `default-terminal "tmux-256color"`.
- Whether other agents change their screen with `TERM=screen`.
- Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/057-kilo-can-draw-nothing-while-npm-runs.md

# 057. Kilo Code CLI can draw nothing for 30 s while a child npm runs

## Measured

2026-10-30, Kilo Code CLI 7.8.18 (npm `@kilocode/cli`), the scenario
`scenarios/first-run.sh kilo kilo` in the scenarios workflow (run
41142220844), with a throwaway `HOME`, no login and no key. The scenario
records the screen, the processes and the files below `HOME` at each step.
The step `02-after-20s` came about 30 s after the start on macos-26-intel,
and about 20 s after the start on the other labels. The data comes from the
scrubbed summary in the job logs and from the scrubbed artifact.

Measured on: CI runner macos-26-intel (x64). For comparison: CI runner
ubuntu-24.04 (x64), ubuntu-22.04-arm (arm64), macos-15, macos-26 (arm64)
and macos-15-intel (x64). The screens of ubuntu-22.04, ubuntu-26.04,
ubuntu-24.04-arm and ubuntu-26.04-arm were also compared.

## What was measured

1. On macos-26-intel, the pane was empty at the step `02-after-20s`: 40
   empty lines. On the other nine labels, Kilo Code CLI showed its input box
   at that step.
2. At that step on macos-26-intel, the TUI process `.kilo` had a child
   process `npm list` with no tty (`??`). On the five other labels whose
   processes were read, no `npm list` process was there at that step.
3. On each of the six labels whose files were read, Kilo Code CLI made
   `.npm/_logs/<time>-debug-0.log` and `.npm/_update-notifier-last-checked`
   below `HOME`. The time in the name of the npm log came after the line
   "version:" of the scenario log:

   | Label | Delay of the npm log |
   |---|---|
   | ubuntu-24.04 | 3 s |
   | ubuntu-22.04-arm | 4 s |
   | macos-26 | 5 s |
   | macos-15 | 7 s |
   | macos-15-intel | 8 s |
   | macos-26-intel | 19 s |

4. On macos-26-intel, the TUI already held `.local/share/kilo/kilo.db` (with
   `-wal` and `-shm`) and two logs in `.local/share/kilo/log/` open, as on
   the other labels.

## Mechanism

Kilo Code CLI starts npm on each first start. On the slowest runner, the npm
child still ran when the other labels had drawn the box, and the pane stayed
empty. This suggests that the TUI waits for npm before it draws. The source
of Kilo Code CLI was not read, and one run does not prove the cause.

A tool must not read an empty pane of a new agent process as a dead or idle
agent. The state is `NO_BOX`: the agent has not drawn its box yet.

## Incident

None.

## Screens

- `kilo/idle-v7-8-18` (ubuntu-24.04, the input box)
- `kilo/blank-v7-8-18` (macos-26-intel, the empty pane)

## Not measured

- Whether the empty pane comes again on macos-26-intel in another run. Fact
  46 gives the input box for all labels in two earlier runs.
- How long the pane stays empty, and the first screen after npm ends.
- What `npm list` reads, and whether opencode does the same.
- Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/061-the-first-start-of-thirteen-more-agents.md

# 061. The first start of thirteen more agents with no login

## Measured

2026-10-31, the scenario `scenarios/first-run.sh <agent> <command>` in the
scenarios workflow (run 41151440753, and before it run 41149533184), with
a throwaway `HOME`, no login and no key. The workflow installed each agent
on the runner. Each install command comes from the page of the vendor or
from the package registry:

| Agent | Command | Version | Install |
|---|---|---|---|
| Kiro CLI | `kiro-cli` | 2.37.0 | `curl -fsSL https://cli.kiro.dev/install \| bash` |
| Junie CLI | `junie` | 26.10.27 (build 3893.6) | `curl -fsSL https://junie.jetbrains.com/install.sh \| bash` |
| Codebuff | `codebuff` | 1.0.688 | npm `codebuff` |
| Qoder CLI | `qodercli` | 1.1.81 | npm `@qoder-ai/qodercli` |
| CodeBuddy Code | `codebuddy` | 2.179.0 | npm `@tencent-ai/codebuddy-code` |
| Letta Code | `letta` | 0.34.35 | npm `@letta-ai/letta-code` |
| Neovate Code | `neovate` | 0.28.5 | npm `@neovate/code` |
| Every Code | `coder` | 0.6.196 | npm `@just-every/code` |
| iFlow CLI | `iflow` | 0.5.19 | npm `@iflow-ai/iflow-cli` |
| Mistral Vibe | `vibe` | 3.0.4 | `uv tool install --python 3.12 mistral-vibe` |
| gptme | `gptme` | 0.35.1 | `uv tool install --python 3.12 gptme` |
| Open Interpreter | `interpreter` | 0.0.56 | `curl -fsSL https://www.openinterpreter.com/install \| sh` |
| Grok CLI | `grok` | 1.1.7 | the `install.sh` of the `superagent-ai/grok-cli` README |

Node.js was 22.23.4 (from `actions/setup-node`) on each runner. Grok CLI is
a project of superagent-ai for the xAI API, not a program of xAI.

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64). Each agent installed and started on each of these
runners, except Grok CLI. The Grok CLI installer stopped with
"Unsupported platform: linux-arm64" on the three arm64 Linux images and
with "Unsupported platform: darwin-x64" on the two Intel macOS images.

## What was measured

The screen after 20 s, the processes, the files below the throwaway `HOME`,
and the files that the processes held open, on ubuntu-24.04 (x64) unless
an item names another label. The paths are relative to `HOME`.

1. Kiro CLI writes "Welcome to Kiro CLI, let's get you signed in!" and
   "Press enter to continue to the browser or esc to cancel". It runs as
   one native process `kiro-cli`. It holds
   `.local/share/kiro-cli/data.sqlite3` open and makes
   `.kiro/settings/cli.json`. On macos-26-intel the screen after 20 s was
   a menu "You are not logged in. Login now?" with "❯ Yes" and "No".
2. Junie CLI draws a logo of slashes and asks "Share anonymous statistics"
   with "→ Yes, share anonymous statistics" and "No, don't share". The
   process is `~/.local/share/junie/versions/3893.6/junie-app/bin/junie`
   in the real `HOME`: the scenario passes `JUNIE_DATA`, because the shim
   finds the binary below `$HOME/.local/share/junie`. Below the throwaway
   `HOME`, Junie made only `.rpmdb/rpmdb.sqlite` with `-wal` and `-shm`.
   The logo has an animation: on macos-26-intel some of its characters
   were other characters.
3. Codebuff draws CODEBUFF in large letters and "Press ENTER to login...".
   It runs as `node .../bin/codebuff` with a native child. On Linux, `ps`
   shows the work folder as the command of the child. A third process
   `/bin/sh -c cat >/dev/null 2>&1; printf '\033[?1049l...` with no tty
   waits as a child of the native process. Codebuff makes
   `.config/manicode/` and holds
   `.config/manicode/projects/example/chats/<time>/log.jsonl` open. The
   first `codebuff --version` downloads the binary and prints "Download
   complete! Starting Codebuff..." before the version.
4. Qoder CLI shows "Qoder CLI v1.1.81", "Not Login Please Auth", a box
   "Tips for getting started", and a menu "❯ 1. Sign in to continue",
   "2. Exit the application". It runs as `node .../bin/qodercli`. It makes
   about 230 files in `.qoder/` and holds a log in `.qoder/logs/runs/` and
   a `.jsonl` file in `.qoder/logs/sessions/-work-example/<uuid>/segments/`
   open. On ubuntu-22.04 and ubuntu-22.04-arm it adds a warning "Limited
   color support detected (TERM=screen)".
5. CodeBuddy Code asks "Do you trust the files in this folder?" with four
   numbered options, "1. Trust folder only (example)" under the mark. It
   runs as `node .../bin/codebuddy`. It makes `.codebuddy/` with about
   5,400 files in `.codebuddy/plugins/marketplaces`, and
   `sessions/<pid>.json`, `web-ui-port.json` and `user-state.json`.
6. Letta Code shows "Welcome to Letta Code" and a menu "> Sign in with
   Letta (default)", "Proceed locally", "Exit". It runs as
   `node .../bin/letta` and makes `.letta/settings.json`. On the four
   macOS labels the first line shows "^[[?1;2;4c" as text.
7. Neovate Code shows a framed list of providers with "/login" and
   "/model" as suggested actions, and below it an empty input line ">"
   between two rules, with a status line that ends in "🆔" and eight hex
   digits. The digits changed from start to start. It runs as
   `node --no-warnings=ExperimentalWarning .../bin/neovate`. It made no
   file below `HOME` in 20 s.
8. Every Code shows ">_ Welcome to Code" and a menu "> 1. Sign in with
   ChatGPT", "2. Provide your own API key" on five labels. On ubuntu-24.04,
   ubuntu-26.04, ubuntu-26.04-arm, macos-26 and macos-15-intel the pane
   was still empty after 20 s. It runs as `node .../bin/coder` with a
   native child `code-<target>` (on Linux x64
   `code-x86_64-unknown-linux-musl`). It makes `.code/version.json` and
   holds `.code/debug_logs/critical.log.<date>` open.
9. iFlow CLI shows a framed header with tips and a form "OpenAI Compatible
   API Configuration" with "Base URL:" and "https://api.openai.com/v1" in
   the field. It runs as `node .../bin/iflow` with a second `node` child.
   It makes `.iflow/` and holds `.iflow/log/console-<time>-<pid>.log` open.
10. Mistral Vibe shows "Welcome to Mistral Vibe - Let's get you started!"
    and "Enter continue". It runs as the native `vibe-rs` from its uv tool
    folder, with a child `vibe-app-server`. It makes `.vibe/` and holds
    `.vibe/logs/vibe-rs.log` and `.vibe/logs/vibe.log` open.
11. gptme asks "New conversation or load previous?" with "* New
    conversation" and "Load more". It runs as the Python of its uv tool
    folder. It made no file below `HOME` in 20 s.
12. Open Interpreter shows "Welcome to Open Interpreter" and a menu "> 1.
    Sign in with ChatGPT", "2. Sign in with Device Code", "3. Provide your
    own API key". It runs as one native process `interpreter`. Its files
    are in `.openinterpreter/` (fact 65).
13. Grok CLI asks on plain lines "Run grok directly on the host for this
    directory?" with "[Y] Yes, remember host mode", "[s] Yes, this session
    only" and "Choice [Y/s]:". On macos-15 and macos-26 (arm64) it asks
    "Run grok in sandbox mode for this directory?" with three choices. It
    runs as one native process `grok` and made no file below `HOME` in 20 s.

## Mechanism

Only Neovate Code starts at an input line. The other twelve agents first
show a login, a key or provider form, a trust question, a statistics
question or a choice of the conversation.

Junie CLI and the first `--version` call of Codebuff and Every Code show
two install patterns. The Junie shim runs a binary from a data folder
below `HOME`, so a throwaway `HOME` needs `JUNIE_DATA`. Codebuff and Every
Code download or install their binary at the first call. The scenario
takes the version from a second call when the first line says "Download"
or "Installing".

Codebuff and Open Interpreter run their native process with the work
folder or a short name as the command line, so a reader that finds an
agent by its command line must not expect the package path.

## Incident

The first run (41149533184) installed Junie CLI with npm
`@jetbrains/junie`. The shim of that package looked for its binary below
the throwaway `HOME`, stopped before 5 s, and the pane closed, so the
capture was "no pane". The scenario now keeps the pane of an agent that
stops (`remain-on-exit`), and the workflow installs Junie with its own
installer.

## Screens

- `corpus/kiro/screens/login-v2-37-0`
- `corpus/junie/screens/statistics-v26-10-27`
- `corpus/codebuff/screens/login-v1-0-688`
- `corpus/qoder/screens/login-v1-1-81`
- `corpus/codebuddy/screens/trust-v2-179-0`
- `corpus/letta/screens/backend-v0-34-35`
- `corpus/neovate/screens/no-model-v0-28-5`
- `corpus/everycode/screens/login-v0-6-196`
- `corpus/iflow/screens/base-url-v0-5-19`
- `corpus/vibe/screens/welcome-v3-0-4`
- `corpus/gptme/screens/conversation-v0-35-1`
- `corpus/interpreter/screens/login-v0-0-56`
- `corpus/grok/screens/host-mode-v1-1-7`

## Not measured

- The screens after a login, and any turn.
- Where Junie CLI writes its state on Linux and macOS. The Linux scenario
  does not list the real `HOME`, and Junie made no `.junie` folder below
  the throwaway `HOME`. On Windows it wrote to the real profile (fact 64).
- Why Every Code drew nothing in 20 s on five labels, and whether it draws
  later.
- Whether the Codebuff process with no tty stays after the TUI stops.
- The npm package `@jetbrains/junie` after a fix of the shim lookup.
- Grok CLI on arm64 Linux and on Intel macOS.
- Agents that the workflow does not install (see the pull request): Warp
  Oz, Plandex, Mentat, Trae Agent, Roo Code, Zed and Charm Mods.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/062-codex-home-moves-all-codex-files.md

# 062. CODEX_HOME moves all files of Codex CLI, also on Windows

## Measured

2026-10-31, Codex CLI 0.166.0 from npm `@openai/codex`, in the scenarios
workflow (run 41151440753, and before it run 41149533184). The scenario
name `codex-home` starts `codex` with `CODEX_HOME=<throwaway folder>/.codex`.
That folder is next to the throwaway home, not in it, so that a file in it
cannot be a file of the default `~/.codex`. The scenario makes the folder
before the start. On Linux and macOS the run is
`scenarios/first-run.sh codex-home codex`. On Windows the run is
`scenarios/first-run-windows.py codex-home codex`, before the normal
`codex` run of the same job, with USERPROFILE, HOME, APPDATA, LOCALAPPDATA,
TEMP and TMP in the throwaway folder as in fact 53.

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64); CI runner windows-2022, windows-2025 (x64) and
windows-11-arm (arm64).

## What was measured

1. On each Linux and macOS label, Codex CLI made no file below the
   throwaway `HOME`. It made 5,504 files in the `CODEX_HOME` folder on
   Linux and on macos-15, and 5,505 on the other three macOS labels: the
   same names as in `~/.codex` of the normal run (fact 29): `config.toml`,
   `installation_id`, `version.json`, `.tmp/plugins` (about 5,400 files),
   `skills/.system`, `tmp/` (on Linux `tmp/arg0-linux/`), and the SQLite
   files `state_5`,
   `logs_2`, `goals_1`, `memories_1` and `queue_1`, each with `-wal` and
   `-shm`.
2. On Linux the process held the five SQLite files with `-wal` and `-shm`
   and `tmp/arg0-linux/codex-arg0<random>/.lock` open, all in the
   `CODEX_HOME` folder.
3. On the three Windows images, Codex CLI made 5,507 files in the
   `CODEX_HOME` folder: the same names, `.sandbox`, and three files in
   `tmp`. It made 0 changes in the real profile on windows-2022 and
   windows-2025. On windows-11-arm the one change was
   `%LOCALAPPDATA%\Packages`, which also changes with no agent (fact 55).
4. In the same jobs, the normal `codex` run after it made 22 changes in the
   real profile on windows-2022 and windows-2025, and 23 on
   windows-11-arm: the real `%USERPROFILE%\.codex` of fact 53.
5. The first screen was the same as with no `CODEX_HOME` (fact 52).
6. On Windows, the driver could not delete the throwaway folder after the
   `codex-home` run ("could not delete the throwaway folder"). The
   processes below the driver were stopped before that.

## Mechanism

Codex CLI takes its folder from `CODEX_HOME` when the variable is set, and
from the profile folder of the account when it is not set. On Windows, the
profile folder comes from Windows, not from USERPROFILE or HOME (fact 53).
`CODEX_HOME` is the one variable that keeps Codex CLI out of the real
profile on Windows.

A tool that looks for the Codex files of a session must read `CODEX_HOME`
from the environment of the process first, and use `~/.codex` only when
the variable is not set.

## Incident

Before this fact, each Windows first run wrote a Codex state into the real
profile of the runner (fact 53). The `codex-home` run does not.

## Screens

None. The screen is the screen of fact 52.

## Not measured

- Which process held files in the throwaway folder after the stop on
  Windows.
- A login, a turn, and the session files with `CODEX_HOME`.
- Whether the Codex app-server and its daemon use `CODEX_HOME` too.
- A `CODEX_HOME` folder that does not exist before the start.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/063-opencode-2-starts-a-service-process.md

# 063. opencode 2 installs as @opencode/cli and starts a service process

## Measured

2026-10-31, opencode 2.2.5 from npm `@opencode/cli`, in the scenarios
workflow (run 41151440753, and before it run 41149533184). On Linux and
macOS the scenario was `scenarios/first-run.sh opencode2 opencode2`, on
Windows `scenarios/first-run-windows.py opencode2 opencode2`, with a
throwaway home, no login and no key. The workflow installs opencode 2 in
group b, where the opencode 1 package `opencode-ai` is not installed.

The install method comes from the README of `anomalyco/opencode`:
`curl -fsSL https://opencode.ai/v2/install | bash` or
`npm i -g @opencode/cli@latest`. The opencode 1 installer
(`https://opencode.ai/install`) refuses a 2.x version and names the v2
installer. The npm package `opencode-ai` has the `latest` tag 1.19.5. The
package `@opencode/cli` has the `latest` tag 2.2.5 and two commands,
`opencode` and `opencode2`, for the same `bin/opencode.exe`. The GitHub
releases of `anomalyco/opencode` hold 2.x archives for Linux, macOS and
Windows (x64 and arm64).

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64); CI runner windows-2022, windows-2025 (x64) and
windows-11-arm (arm64).

## What was measured

1. `opencode2 --version` printed "opencode v2.2.5". opencode 1.19.5 prints
   "1.19.5" (fact 29).
2. On each label, opencode 2 started in its input box: the logo, a box
   with "Ask anything… "<example>"" and "Build · Big Pickle OpenCode", the
   folder with "shift+tab agents ctrl+p commands", and "2.2.5" at the
   bottom right. Only the example in the placeholder and the folder
   changed between labels. opencode 1.19.5 shows "tab agents" and the note
   "/update to upgrade to OpenCode 2.0" (fact 29).
3. opencode 2 runs two processes. On ubuntu-24.04 they were `opencode2`
   on the pane tty and a child
   `.../node_modules/@opencode/cli/bin/opencode.exe serve --service` with
   no tty (`?`). On macos-15 the child had no tty too (`??`). On Windows
   the tree was `cmd.exe /d /c ...\opencode2.cmd`, `opencode.exe`, and a
   child `opencode.exe serve --service`.
4. On ubuntu-24.04, opencode 2 held `.local/share/opencode/opencode.db`
   (with `-wal` and `-shm`) and `.local/share/opencode/log/opencode.log`
   open, as opencode 1 does. It made `.config/opencode/service.json`, four
   files in `.local/share/opencode` and two in `.local/state/opencode`. It
   made no `node_modules` in `.config/opencode`: opencode 1.19.5 made
   about 3,650 files there in the same run.
5. On windows-11-arm, opencode 2 also made
   `.cache/opencode/opencode-service-<pid>-<hex>.exe` and 545 files in
   `AppData/Local/Temp` of the throwaway home. It made no change in the real
   profile folders.

## Mechanism

opencode 2 starts its server as a second process (`serve --service`) and
writes `service.json` in its config folder. The TUI is a client of that
service. This explains the second process, but the source was not read.
A reader that maps a process to a terminal must skip the service process,
as it skips the Cline daemon (fact 46).

opencode 1 and opencode 2 use the same folder names (`opencode.db`,
`log/opencode.log`). A reader that finds an opencode database cannot tell
the major version from the folder name.

## Incident

None.

## Screens

- `corpus/opencode2/screens/idle-v2-2-5`

## Not measured

- Whether the service process stays after the TUI stops, and whether a
  second TUI uses the same service.
- The contents of `service.json` and of the database.
- The install with `https://opencode.ai/v2/install`, Homebrew, or the
  release archives.
- opencode 2 and opencode 1 on the same machine, with the same folders.
- A login, a turn, and the update from 1.x with `opencode upgrade --major`.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/064-the-first-screens-of-more-agents-on-windows.md

# 064. The first start of more agents on Windows, and four that write to the real profile

## Measured

2026-10-31, the scenario `scenarios/first-run-windows.py <agent> <command>`
in the scenarios workflow (run 41153462586, and runs 41155667724,
41151440753 and 41149533184), in a pseudo console of 120 x 40, with USERPROFILE, HOME,
APPDATA, LOCALAPPDATA, TEMP and TMP in a throwaway folder, no login and no
key. `scenarios/install-windows-agents.ps1` installed the agents of
groups c and d:

| Agent | Version | Install on Windows |
|---|---|---|
| Kiro CLI | 2.37.0 | `irm https://cli.kiro.dev/install.ps1 \| iex` (an x64 MSI) |
| Junie CLI | 26.10.27 (build 3893.6) | `irm https://junie.jetbrains.com/install.ps1 \| iex` |
| Codebuff | 1.0.688 | npm `codebuff` |
| Qoder CLI | 1.1.81 | npm `@qoder-ai/qodercli` |
| CodeBuddy Code | 2.179.0 | npm `@tencent-ai/codebuddy-code` |
| Letta Code | 0.34.35 | npm `@letta-ai/letta-code` |
| Neovate Code | 0.28.5 | npm `@neovate/code` |
| Every Code | 0.6.196 | npm `@just-every/code` |
| iFlow CLI | 0.5.19 | npm `@iflow-ai/iflow-cli` |
| Aider | 0.86.2 | `uv tool install --python 3.12 aider-chat` |
| OpenHands CLI | 1.16.0 | `uv tool install --python 3.12 openhands` |
| gptme | 0.35.1 | `uv tool install --python 3.12 gptme` |
| Mistral Vibe | 3.0.4 | `uv tool install --python 3.12 mistral-vibe` |
| Goose | 1.57.0 | `download_cli.ps1` of the `block/goose` repository, with `CONFIGURE=false` |
| Open Interpreter | 0.0.56 | `irm https://www.openinterpreter.com/install.ps1 \| iex` |

Measured on: CI runner windows-2022 (x64), CI runner windows-2025 (x64) and
CI runner windows-11-arm (arm64).

## What was measured

1. These agents started and showed the same first question as on Linux
   (fact 61, fact 46) on the three images: Junie CLI, Qoder CLI, CodeBuddy
   Code, Letta Code and Open Interpreter. Codebuff, Every Code, Aider,
   OpenHands CLI, Mistral Vibe and Goose did the same on the two x64
   images. Aider asked "No git repo found, create one to track aider's
   changes (recommended)? (Y)es/(N)o [Yes]:".
2. Some screens differ from Linux:
   - Kiro CLI shows "You are not logged in. Login now?" with "> Yes" and
     "No", as on macos-26-intel (fact 61), on the three images.
   - iFlow CLI draws IFLOW in large block letters above its header box, in
     place of the small logo at the left of the box on Linux.
   - Neovate Code draws its list bullets as "*", not "•".
   - gptme asks "New conversation or load previous?" with "0: New
     conversation", "1: Load more" and "Select option number:", in place
     of a menu with a mark (x64 only).
3. Four agents wrote to the real profile folders, not to the throwaway
   home, on each image where they started:
   - Open Interpreter: 21 changes in `%USERPROFILE%\.openinterpreter`
     (`config.toml`, `installation_id`, `version.json`, `.tmp`, `skills`,
     and the SQLite files `state_5`, `logs_2`, `goals_1`, `memories_1` and
     `queue_1` with `-wal` and `-shm`), as Codex CLI does (fact 53).
   - Every Code: `%USERPROFILE%\.code` with `debug_logs` and
     `version.json`.
   - Junie CLI: `%USERPROFILE%\.junie` with `settings.json`,
     `history.jsonl`, `sessions`, `processes`, `instances`, `versions`,
     `misc` and `logs`.
   - Kiro CLI: `%USERPROFILE%\.kiro\settings`.
4. The other new agents made no change in the real profile, or only
   changes that also happen with no agent (fact 55): CodeBuddy Code,
   Letta Code, Neovate Code, Qoder CLI, Codebuff, Mistral Vibe, gptme,
   OpenHands CLI, Goose and opencode 2 (fact 63). iFlow CLI changed the
   folder `%USERPROFILE%\.iflow`, which existed before the start.
5. Processes and folders:
   - Kiro CLI runs as one process `kiro-cli.exe` from
     `%LOCALAPPDATA%\Kiro-Cli`. The installer prints "installed to
     C:\Program Files\Kiro-Cli\", but the file is not there. The x64 MSI
     installed and ran on windows-11-arm too.
   - Junie CLI runs as `cmd.exe /d /c ...\.local\bin\junie.bat`, then
     `junie.exe` and a second `junie.exe`, from
     `%USERPROFILE%\.local\share\junie\versions\3893.6\junie\`.
   - Codebuff runs as `node ...\codebuff\index.js` with a child
     `codebuff.exe` from `.config\manicode\` of the throwaway home. A
     `powershell.exe` that is not below the driver writes a file in the
     throwaway folder (`[System.IO.File]::WriteAllText(...)`).
   - Every Code runs as `node ...\coder.js` with a child
     `code-x86_64-pc-windows-msvc.exe` from
     `AppData\Local\just-every\code\0.6.196\` of the throwaway home. Its
     `--version` printed "Installing @just-every/code v0.6.196 for
     x86_64-pc-windows-msvc..." on both calls.
   - Mistral Vibe runs as eight processes: `vibe.exe`, two Python
     processes, `vibe-rs.exe`, `vibe-app-server.exe` and two more Python
     processes.
6. Installs that failed:
   - On windows-11-arm, `uv tool install` of `aider-chat`, `openhands`,
     `gptme` and `mistral-vibe` failed. uv tried to build `hf-xet` or
     `cryptography` from source ("Failed to build `cryptography==50.0.2`",
     "failed to run custom build command for `openssl-sys v0.9.117`").
   - On windows-11-arm, the Goose script stops ("Windows ARM64 is not
     currently supported.").
   - On windows-11-arm, Every Code stopped at the start with "Unsupported
     platform" in `coder.js`.
   - On windows-11-arm, Codebuff stopped with "❌ Failed to download
     codebuff: Unsupported platform: win32 arm64" (run 41155667724). In run
     41153462586 the driver could not print that line in the code page of
     the console ("UnicodeEncodeError"). The driver now writes UTF-8.
   - The npm package `@jetbrains/junie` on Windows (run 41149533184)
     printed "[Junie] Shim not found at ~\.local\bin\junie" also with the
     real profile.

## Mechanism

Open Interpreter has the file layout of Codex CLI (fact 65). Like Codex
CLI, it takes its folder from Windows, not from USERPROFILE or HOME. Every
Code is a fork of Codex CLI (its npm description says so) and does the
same with `.code`. Junie CLI is a JVM program: the JVM takes the home
folder from Windows. Kiro CLI also ignores USERPROFILE. The source of these
agents was not read.

A tool that finds the files of these agents on Windows must look in the
profile folder of the account. A scenario that must not touch the real
profile cannot use these four agents with a throwaway USERPROFILE alone.

## Incident

The first runs wrote state of these four agents into the real profile of
each runner. The runner is thrown away after the job.

## Screens

None. The Linux screens are in the corpus (fact 61).

## Not measured

- A variable like `CODEX_HOME` for Open Interpreter, Every Code, Junie CLI
  or Kiro CLI (fact 62 has the Codex case).
- Grok CLI on Windows: its README gives a bash installer only.
- What the PowerShell process of Codebuff writes.
- Why `%USERPROFILE%\.qoder` changed during the runs of other agents.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/065-open-interpreter-keeps-the-codex-file-layout.md

# 065. Open Interpreter 0.0.56 keeps the file layout of Codex CLI

## Measured

2026-10-31, Open Interpreter 0.0.56, the Rust version from the installer
`https://www.openinterpreter.com/install` (Linux and macOS) and
`https://www.openinterpreter.com/install.ps1` (Windows), in the scenarios
workflow (run 41151440753, and runs 41149533184 and 41153462586). The
scenario was `scenarios/first-run.sh interpreter interpreter` and
`scenarios/first-run-windows.py interpreter interpreter`, with no login.
In the same jobs, Codex CLI 0.166.0 ran with the same scenario (facts 29,
53 and 62).

The GitHub releases of `OpenInterpreter/open-interpreter` have the tags
`rust-v0.0.56` and `rust-v0.0.55`. The Linux installer reads the variables
`OPEN_INTERPRETER_INSTALL_DIR` or `CODEX_INSTALL_DIR`, and
`OPEN_INTERPRETER_COMMAND_NAME` or `CODEX_COMMAND_NAME`. It installs
`interpreter`, the alias `i`, and `codex-code-mode-host` in
`~/.local/bin`.

Measured on: CI runner ubuntu-22.04, ubuntu-24.04, ubuntu-26.04 (x64);
CI runner ubuntu-22.04-arm, ubuntu-24.04-arm, ubuntu-26.04-arm (arm64);
CI runner macos-15, macos-26 (arm64); CI runner macos-15-intel,
macos-26-intel (x64); CI runner windows-2022, windows-2025 (x64) and
windows-11-arm (arm64).

## What was measured

1. On ubuntu-24.04, Open Interpreter made `~/.openinterpreter/` with the
   same names as `~/.codex/` of Codex CLI 0.166.0: `config.toml`,
   `installation_id`, `version.json`, `.tmp/plugins` (5,434 files),
   `.tmp/plugins.sha`, `.tmp/plugins.sync.lock`, `skills/.system`, `tmp/`,
   and the SQLite files `state_5`, `logs_2`, `goals_1`, `memories_1` and
   `queue_1`, each with `-wal` and `-shm`. Codex CLI made 49 files in
   `skills/.system`, Open Interpreter 62.
2. The process held the five SQLite files with `-wal` and `-shm` open, and
   `.openinterpreter/tmp/arg0/codex-arg0<random>/.lock`. The lock folder
   of Codex CLI is `tmp/arg0-linux/codex-arg0<random>/`.
3. The first screen has the layout of the Codex CLI screen: "Welcome to
   Open Interpreter", a sign-in text, a numbered menu "> 1. Sign in with
   ChatGPT", "2. Sign in with Device Code", "3. Provide your own API key",
   each with a line of help, and "Press enter to continue". Codex CLI
   0.166.0 has a fourth option "Use Amazon Bedrock".
4. The ten Linux and macOS labels gave the same bytes for the screen.
5. On Windows, Open Interpreter made the same entries in the real
   `%USERPROFILE%\.openinterpreter` (21 changes), and none in the
   throwaway home, on the three images (fact 64).

## Mechanism

The installer variables, the binary `codex-code-mode-host` and the file
names show that Open Interpreter 0.0.56 is built from the source of Codex
CLI, with the folder `.codex` renamed to `.openinterpreter`. The source
was not compared.

A reader of Codex sessions can read the files of Open Interpreter with the
same rules, in another folder. A tool that finds a process by the name
`codex` or by a path with `.codex` does not find Open Interpreter.

## Incident

None.

## Screens

- `corpus/interpreter/screens/login-v0-0-56`

## Not measured

- Whether a variable such as `CODEX_HOME` or `OPEN_INTERPRETER_HOME`
  moves the folder.
- The session files, the hooks and the app-server after a login.
- The Python Open Interpreter (`open-interpreter` on PyPI, 0.4.3). The
  README says that it continues as a fork of the community
  (`endolith/open-interpreter`).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/066-claude-pid-files-outside-tmux.md

# 066. The Claude pid files outside tmux: stale files, the version of the process, and no tmux key

## Measured

2026-10-31, Claude Code 2.1.316 installed, seven interactive processes of
2.1.287, 2.1.288, 2.1.295, 2.1.311, 2.1.312 and 2.1.314, on macOS 26.6.2
(arm64). All processes ran in the terminal of a JetBrains IDE (PyCharm),
not in tmux. The probe kit (`probes/run.sh`, probe `claude/unix.sh`)
read `ps`, `lsof`, and the keys of each `~/.claude/sessions/<pid>.json`.
It read no values other than `status`, `kind` and `version`.

The same day, the kit ran on Ubuntu 24.04.5 (x64), with Claude Code
2.1.314 installed. One interactive process of 2.1.292 ran in GNOME
Terminal, not in tmux. One other `claude` process ran.
Measured on: real machine.

## What was measured

1. Each of the seven processes had a `<pid>.json` and a
   `<pid>.<hex>.key` file. `status` was `idle` and `kind` was
   `interactive` in all seven.
2. `version` in the pid file is the version of the running process, not
   the installed version. The installed command gave 2.1.316. The pid
   files gave six older versions. The oldest process started 29 days
   before the probe.
3. The folder `~/.claude/sessions/` held pid files for nine pids. Two of
   them (`.json` and `.key`) had no process with that pid. Their `status`
   was `idle`. Claude does not delete the pid file of a process that
   stopped, at least not in every case.
4. No pid file had the key `tmux`, on macOS and on Ubuntu. Fact 023 saw
   the key, empty or with a pane, in tmux on Linux. Outside tmux, these
   versions do not write it.
5. The pid files had keys that fact 023 does not list: `pidDomain`,
   `peerProtocol`, `peerFeatures`, `nameSince` and `nameSource` in all
   seven, `bridgeSessionId` in three, and `asksForConvertedSkills` in one
   (2.1.314).
6. The processes held no file below `~/.claude/` and no file below
   `/tmp/claude-<uid>/` open (`lsof -Fn`). The folder `/tmp/claude-501/`
   existed with 11 entries. On Ubuntu, the process held
   `/tmp/claude-1000/<project key>/<uuid>/tasks` open, as in fact 025.
7. Five processes ran as `pycharm` > `/bin/zsh` > `claude`. Two ran as
   `pycharm` > `~/.local/bin/claude`, with no shell between them.
8. The last records of the newest transcript had the types `assistant`,
   `user`, `attachment`, `system`, `last-prompt`, `ai-title`, `mode`,
   `permission-mode`, `atis-latch`, `pr-link` and `bridge-session`.
9. On Ubuntu, a second process ran as `~/.local/bin/claude --chrome-native-host`.
   Its parent was `chrome`, it had no tty, its working folder was
   `~/.claude/chrome`, and it had no pid file. It is the native messaging
   host of the Claude browser extension, not a session.
10. On macOS, during a 30 s guided step, a new pid file appeared, with `status`
   `idle`, 6 s after the start of the step. The step did not start that
   process.

## Mechanism

A pid file proves a session only when its process lives. A reader must
check that the pid runs and that its start time is `procStart` of the
file, because the system can give the pid of a stopped process to a new
process.

A reader must not take the pane of a session from the `tmux` key outside
tmux. When the key is absent, the process is not in tmux, or its version
does not write the key.

On macOS, the task folder of fact 025 does not link a process to its
session. The pid file does (fact 023).

A process match on `claude` also finds the browser host. A reader must
skip a process with `--chrome-native-host`, or a process with no tty and
no pid file.

## Incident

None.

## Screens

None.

## Not measured

- Why the two stale pid files stayed: a crash, a kill, or a stop that
  skips the clean-up.
- The values of the new keys.
- Whether a process on macOS holds its task folder open while a turn
  runs. All seven processes were idle.
- Which program started the two processes that have no shell.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/067-the-codex-daemon-outlives-the-tui.md

# 067. The Codex app-server daemon runs with no TUI and updates on its own

## Measured

2026-10-31, Codex CLI 0.164.0 (standalone install), on macOS 26.6.2
(arm64). The probe kit (`probes/run.sh`, probe `codex/unix.sh`) read
`ps`, `lsof` and the names in `~/.codex/`. It read no content.

The same day, the kit ran on Ubuntu 24.04.5 (x64), with the same Codex
CLI version. It also ran on Windows 11 Pro 10.0.26300 (x64), with Codex CLI
0.164.0 installed in `~\AppData\Local\Programs\OpenAI\Codex\bin\`.
Measured on: real machine.

## What was measured

1. No Codex TUI ran. Two daemon processes ran:
   - `~/.codex/packages/app-server-daemon/releases/0.166.0-aarch64-apple-darwin/bin/codex`,
     with parent process 1 and no tty. It started about 23 h before the
     probe.
   - A child of that process, the same program, with
     `--listen unix:// --analytics-default-enabled --managed-daemon`.
2. On Ubuntu, the same two processes ran from
   `releases/0.166.0-x86_64-unknown-linux-musl/`. The parent of the daemon
   was the `systemd` user manager, not process 1. The daemon started 7 days
   before the probe, and its child 2 days before the probe.
   `app-server-daemon/releases/` also held 0.165.0. No TUI ran.
3. On Windows, three processes ran with no TUI:
   `codex.exe app-server --listen unix:// --analytics-default-enabled --managed-daemon`,
   its child `codex-code-mode-host.exe`, and `codex.exe app-server daemon <arg>`.
   Their path was
   `\\?\~\.codex\packages\app-server-daemon\releases\0.166.0-x86_64-pc-windows-msvc\bin\`.
   The daemon listens on `unix://` on Windows too:
   `~\.codex\app-server-control\app-server-control.sock`.
   `~\.codex\app-server-daemon\` held `daemon.pid`, `daemon-updater.pid`,
   their `.lock` files and `.stderr.log` files.
   `~\.codex\packages\app-server-daemon\` held `auto-update-version`
   and `selection-history`.
4. The daemon was version 0.166.0 on all three machines. The command `codex` gave
   `codex-cli 0.164.0`. `~/.codex/packages/` held
   `app-server-daemon/releases/0.164.0-…`, `app-server-daemon/releases/0.166.0-…`
   and `standalone/releases/0.164.0-…`.
5. The daemon held no rollout file and no thread lock open.
6. `~/.codex/` held these names that fact 026 does not list:
   `app-server-control/`, `app-server-daemon/`, `goals_1.sqlite`,
   `memories_1.sqlite`, `queue_1.sqlite`, `thread_history_1.sqlite`,
   `tui-thread-reference-capabilities/` and `.sqlite-maintenance.lock`.
   Ubuntu had the same names.
7. The last records of the newest rollout file had the types
   `event_msg` (`thread_settings_applied`, `task_started`,
   `item_completed`, `token_count`, `task_complete`), `turn_context`,
   `response_item` (`message`) and `token_usage_record`.

## Mechanism

The daemon of fact 026 does not stop when the last TUI stops. It updates
from its own release folder, so its version can be newer than the
version of the `codex` command.

A reader that finds a daemon must not count it as a session. A reader
that reports the Codex version must say whose version it is: the
command, or the daemon that holds the rollout files.

## Incident

None.

## Screens

None.

## Not measured

- When the daemon stops, and what updated it to 0.166.0.
- Whether a TUI of 0.164.0 uses the daemon of 0.166.0.
- The tables of the new SQLite files.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/068-the-open-files-of-agy-1-4-12.md

# 068. The open files of agy 1.4.12 on macOS and Ubuntu

## Measured

2026-10-31, Antigravity CLI (agy) 1.4.12, on macOS 26.6.2 (arm64), one
process started as `agy --dangerously-skip-permissions -c` in
Terminal.app. The probe kit (`probes/run.sh`, probe `agy/unix.sh`) read
`ps` and `lsof`.

The same day, the kit ran on Ubuntu 24.04.5 (x64). One process of agy
1.4.12 ran as `agy --dangerously-skip-permissions` in GNOME Terminal. It
had started the day before.
Measured on: real machine.

## What was measured

1. The process chain was `Terminal` > `login` > `-zsh` > `agy`, with a
   tty. The environment had `TERM_PROGRAM=Apple_Terminal` and
   `__CFBundleIdentifier=com.apple.Terminal`.
2. The process held these files open:
   - `~/.gemini/antigravity-cli/conversations/<uuid>.db`, with its
     `-shm` and `-wal` files.
   - `~/.gemini/antigravity-cli/presence/<uuid>.lock`.
3. These are the same paths as on Linux with agy 1.4.7 (fact 028, fact
   044).
4. The process on Ubuntu held only `presence/<uuid>.lock` open, and no
   conversation database. Its chain was `gnome-terminal-server` >
   `zsh` > `agy`.

## Mechanism

The open conversation database links an agy process to its conversation
on macOS too. The link is not always there: the process on Ubuntu held
no database open. The presence lock is there in both cases. The presence lock is the flock lock of fact 044.

## Incident

The probe printed the command line of the process in place of the folder
`~/.gemini/antigravity-cli/` in its layout and log sections. A helper of
`probes/lib.sh` changed a variable of the probe. The fix gives the helper
variables their own names, and `tools/test-probe-lib.sh` checks it.

## Screens

None.

## Not measured

- The layout of `~/.gemini/antigravity-cli/`, because of the probe bug.
- Why the process on Ubuntu held no conversation database: no
  conversation yet, or a database that agy closes when it is idle.
- Whether the presence lock is a flock lock on macOS.
- agy hooks on macOS. The machine had no `~/.gemini/config/hooks.json`.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/069-the-environment-names-the-terminal.md

# 069. The environment of an agent process names its terminal

## Measured

2026-10-31, on macOS 26.6.2 (arm64): seven Claude Code processes, 13
Cursor CLI processes (2026.10.22-27dcf5f and 2026.10.01-e373342), four
Cursor editor agent workers, and one agy process. The probe kit
(`probes/run.sh`) read the terminal variables of each process with
`ps eww`. It reads only a fixed list of names (`terminal_env` in
`probes/lib.sh`), because the environment can hold secrets.

The same day, the kit ran on Ubuntu 24.04.5 (x64) with GNOME, with one
Claude Code and one agy process in GNOME Terminal.
Measured on: real machine.

## What was measured

1. A process in the terminal of a JetBrains IDE had
   `TERMINAL_EMULATOR=JetBrains-JediTerm`, `TERM=xterm-256color` and
   `__CFBundleIdentifier=com.jetbrains.pycharm`. The parent chain ended in
   `~/Applications/PyCharm.app/Contents/MacOS/pycharm`.
2. A process in Terminal.app had `TERM_PROGRAM=Apple_Terminal`,
   `TERM_PROGRAM_VERSION=470.2` and `__CFBundleIdentifier=com.apple.Terminal`.
3. A Cursor editor agent worker had no tty and no `TERM`. It had
   `VSCODE_PID=<pid of the editor>` and
   `__CFBundleIdentifier=com.todesktop.230313mzl4w4u92`. The workers held
   no chat database open (compare fact 021).
4. One Cursor CLI process of 2026.10.01-e373342 ran, but
   `~/.local/share/cursor-agent/versions/` held only 2026.10.18,
   2026.10.19 and 2026.10.22. The update deleted the folder of a version
   that a process still ran.
5. The probe found 505 chat folders below `~/.cursor/chats/`.
6. On Ubuntu, a process in GNOME Terminal had only `TERM=xterm-256color`
   from the list. The list then had no GNOME name. The parent chain was
   `systemd` (the user manager) > `gnome-terminal-` > `zsh` > the agent.
   `ps` cuts the name `gnome-terminal-server` to 15 characters.

## Mechanism

On Linux, the parent chain names the terminal. A reader that matches the
name must accept the 15-character form `gnome-terminal-`. The kit now
also reads `VTE_VERSION`, `GNOME_TERMINAL_SCREEN` and `KONSOLE_VERSION`.

`__CFBundleIdentifier` names the application that started the terminal,
and `TERMINAL_EMULATOR` or `TERM_PROGRAM` names the terminal. A reader can
use them when the parent chain is long or when the terminal program has
a helper process between it and the shell.

The bundle ID of the Cursor editor is not a readable name. A reader must
know it, or use `VSCODE_PID` and the absence of a tty, to tell an editor
worker from a CLI session (fact 022).

## Incident

None.

## Screens

None.

## Not measured

- Other JetBrains IDEs. Their bundle IDs follow the form
  `com.jetbrains.<name>` (not checked).
- iTerm2, Ghostty, WezTerm, kitty, Konsole and the terminal of VS Code.
  None ran.
- The values of `VTE_VERSION` and `GNOME_TERMINAL_SCREEN`. The kit did not
  read them on that run.
- Which terminal tab of PyCharm holds which process. A JetBrains IDE has
  no known scripting access to its tabs (fact 022).

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/070-psmux-starts-each-pane-with-a-long-pwsh-command.md

# 070. psmux starts each pane with a long pwsh command that defines a claude function

## Measured

2026-10-31, psmux with `tmux 3.4.0` from Chocolatey
(`C:\ProgramData\chocolatey\bin\psmux.exe` and `tmux.exe`), PowerShell
7.6.7, Antigravity CLI (agy) 1.4.12 and Claude Code 2.1.314, on Windows 11
Pro 10.0.26300 (x64). The probe kit (`probes/run.ps1`) read the processes
with CIM (`Win32_Process`): the name, the parent, the start time and the
command line.
Measured on: real machine.

## What was measured

1. Two psmux servers ran, each as `tmux.exe`. Each pane was a `pwsh.exe`
   child of a `tmux.exe`. Six pane shells ran.
2. The command line of each pane shell was about 4 KB:
   `pwsh.exe -NoLogo -NoProfile -NoExit -Command "<script>"`. The script:
   - sets PSReadLine options, and the history file from
     `PSMUX_PSREADLINE_HISTORY`;
   - loads the PowerShell profiles by hand, because of `-NoProfile`;
   - replaces `Set-Location`, `Push-Location` and `Pop-Location`, so that
     the process folder follows the shell folder;
   - defines a function `env` that runs a command with variables, in the
     form of the Unix `env`;
   - when `PSMUX_CLAUDE_TEAMMATE_MODE` is set, defines a function
     `claude` that adds `--teammate-mode $env:PSMUX_CLAUDE_TEAMMATE_MODE`,
     unless the settings of Claude Code already set `teammateMode`.
3. An agy process ran as `tmux.exe` > `pwsh.exe` > `agy.exe`.
4. The Claude probe matched the six pane shells as Claude processes,
   because their command line holds the word `claude`. They had no pid
   file. The two real Claude processes ran as `idea64.exe` > `pwsh.exe` >
   `claude.exe`, in the terminal of IntelliJ IDEA, not in psmux.
5. `psmux ls` and `tmux ls` gave the same session list: one session with
   one window and one pane.

## Mechanism

psmux runs the pane shell with `-NoProfile` and its own start script. The
`claude` function exists only in a psmux pane where the variable is set.
A user who types `claude` there starts `claude.exe` with an extra flag,
so the command line of the agent differs from the command line that the
user typed.

A reader that finds agent processes by a word in the command line also
finds psmux pane shells. It must match the program name, `claude.exe`.

## Incident

The kit printed the six command lines in full, 24 KB in total. The probe
fix matches on the program name and cuts each command line.

## Screens

None.

## Not measured

- A Claude Code process in a psmux pane, and the effect of
  `--teammate-mode`.
- Cursor CLI and Codex CLI in psmux: no TUI of these agents ran.
- The values of the psmux variables.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/071-windows-updates-rename-the-running-program.md

# 071. A Windows update renames the running program of Claude Code and agy

## Measured

2026-10-31, Claude Code 2.1.314 and Antigravity CLI (agy) 1.4.12, on
Windows 11 Pro 10.0.26300 (x64). The probe kit (`probes/run.ps1`) listed
the install folders with names, sizes and times, and the processes.
Measured on: real machine.

## What was measured

1. `~\.local\bin\` held `claude.exe` (2.1.314) and two files of the form
   `claude.exe.old.<Unix time in ms>.<pid>`. In one of them, `<pid>` was
   the pid of a Claude process that still ran. That process started 9
   days before the probe.
2. `~\.local\share\claude\versions\` held 2.1.311, 2.1.312 and 2.1.314
   as single files. The size of each `.old` file was the size of one of
   these versions.
3. `~\AppData\Local\agy\bin\` held `agy.exe` and two files of the form
   `agy.exe.<hex>.old`.
4. The Claude process that started 9 days before the probe had a pid file
   with `version` of its own, older version (see fact 066). Two Claude pid
   files existed, one for each live process. They had the same keys as on
   macOS and Linux, and no `tmux` key.
5. A third `claude.exe` ran as `chrome.exe` > `cmd.exe` > `claude.exe
   --chrome-native-host`, with no pid file, as on Ubuntu (fact 066).

## Mechanism

Windows does not let a program replace the file of a running program, but
it lets the program rename the file. The updater renames the old file and
writes the new file in its place. The name keeps the pid of the process
that ran the old file. The `.old` files stay after that process stops.

A reader can take the version of a live process from its pid file. The
file `claude.exe` gives only the newest version.

## Incident

None.

## Screens

None.

## Not measured

- When the updaters delete the `.old` files.
- The meaning of the hex part in the agy name.
- Whether the time in the Claude name is the time of the update. It is in
  ms, and it was within a day of the file time of the `.old` file.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/072-agy-and-cursor-files-on-windows.md

# 072. The agy and Cursor CLI files on Windows

## Measured

2026-10-31, Antigravity CLI (agy) 1.4.12 (one process) and Cursor CLI
2026.10.22-27dcf5f (no process), on Windows 11 Pro 10.0.26300 (x64). The
probe kit (`probes/run.ps1`) listed the state folders with names, sizes
and times. It read no content.
Measured on: real machine.

## What was measured

1. agy keeps its state in `~\.gemini\antigravity-cli\`, with the same
   names as on Linux and macOS: `conversations\<uuid>.db`,
   `presence\<uuid>.lock`, `brain\<uuid>\`, `log\`,
   `conversation_summaries.db`, `history.jsonl` and `settings.json`.
   No agy folder exists below `%APPDATA%` or `%LOCALAPPDATA%` other than
   the install folder `%LOCALAPPDATA%\agy\bin\`.
2. `presence\` held 10 lock files, while one agy process ran. The lock
   files stay after a process stops. Fact 044 shows that a live process
   holds a flock lock on its file on Linux.
3. `log\` held one file for each start, named
   `cli-<yyyyMMdd>_<HHmmss>.log`. `crashes\` held
   `crash_<pid>_<uuid>.log`, with the pid of the process that ran.
4. The last records of the newest agy transcript had the types
   `PLANNER_RESPONSE` and `GENERIC`.
5. Cursor CLI keeps its state in `~\.cursor\` (`chats\<hex>\<uuid>\`,
   `projects\`, `ai-tracking\`, `cli-config.json`), and its login in
   `%APPDATA%\cursor\auth.json`. The commands are `agent.cmd` and
   `cursor-agent.cmd` in `%LOCALAPPDATA%\cursor-agent\`.
6. On Windows, the name of a Cursor project folder is the project path
   with the drive letter and one dash: `C-Users-<name>-<folder>` or
   `D-<folder>`. Claude Code uses two dashes after the drive letter:
   `D--<folder>`.
7. `~\.cursor\` held four files `statsig-cache.json.<pid>.<uuid>.tmp`,
   left from earlier processes.
8. A closed Cursor chat folder held `meta.json`, `prompt_history.json`
   and `store.db`, with no `-wal` and no `-shm` file. The newest transcript
   ended with a `turn_ended` record.

## Mechanism

A presence lock file of agy does not prove a live process on Windows, as
on Linux. A reader must test the lock or find the process.

A project folder name holds the project path, and on Windows also the
drive letter and the account name. A tool that shows or sends these names
must scrub them. The scrub of this repository missed both Windows forms on
this run; the fix adds them.

## Incident

The kit sent project folder names and the account name in the output of
this run, because the scrub did not know the Windows key forms.

## Screens

None.

## Not measured

- Whether agy holds a lock on its presence file on Windows. The open files
  need Sysinternals `handle.exe`.
- A Cursor CLI process on Windows.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/facts/073-agy-in-the-android-terminal-debian-vm.md

# 073. agy in the Debian VM of the Android Terminal app

## Measured

2026-11-01, Antigravity CLI (agy) 1.4.12 (one process), in the Debian
13 (trixie) VM of the Android Terminal app, on aarch64. The VM kernel was
`6.12.93-android16-6-g3a7d1771d492-ab16496487-4k`. Claude Code 2.1.316 was
installed, but no Claude process ran. The probe kit (`probes/run.sh`) ran
one time in full and three times as the guided step `permission` for agy.
It listed names, sizes, times and record types. It read no content.
Measured on: real machine (an Android telephone).

## What was measured

1. The parent chain of the agy process was `agy` -> `bash` -> `ttyd` ->
   pid 1. `ttyd` had no tty. The terminal variables held only
   `TERM=xterm-256color`. No variable named the Android Terminal app.
2. The command line of the process was only `agy`. The command
   `~/.local/bin/agy` was the program, not a link.
3. agy kept its state in `~/.gemini/antigravity-cli/`, with the same
   names as on Linux (x64), macOS and Windows (fact 072). The process held
   open `conversations/<uuid>.db`, its `-shm` and `-wal` files, and
   `presence/<uuid>.lock`, as in fact 028.
4. The process started at 08:36:54. `log/` got the file
   `cli-20261101_083657.log`, 3 s later. `log/` held one file for each of
   four starts.
5. `cli.log` in the top folder had the same size (24070 bytes) as the
   newest file in `log/`.
6. In the first two guided steps, agy started during the step, after the kit.
   The kit counted one agy process before the step, but that process was
   the kit itself: the one-line start ran it as
   `sh -s -- --guided permission agy`, and the agent name matched. The
   kit fix skips the processes that start the kit.
7. A new agy process opened `crashes/crash_<pid>_<uuid>.log` with size 0,
   the new `log/` file and a new presence lock, and held them open. No
   agy crash was seen.
8. In the second step, the start of agy and the first prompt also changed
   `history.jsonl` (one new line), `conversation_summaries.db`,
   `jetbox_summaries_proto.pb`, `annotations/<uuid>.pbtxt`,
   `cache/onboarding.json`, `cache/last_conversations.json`,
   `updater/update_status.json` and `last_check.timestamp`.
9. In the third step, with the fixed kit, the kit found the agy process
   that ran from the second step. During the step, the operator stopped
   agy and started it again. `history.jsonl` got a `slash_command` record
   and one more record. The new process opened a new crash file, a new
   `log/` file and a new presence lock. The old process had closed its
   three files.
10. In each step, the operator asked agy for a file write. In the 30 s
   after that, each new transcript got two records: `USER_INPUT` and
   `PLANNER_RESPONSE`. No record type showed a wait for a permission
   dialog. The changed files also held `conversations/<uuid>.db`, and
   four transcript files in `brain/<uuid>/.system_generated/logs/`:
   `transcript.jsonl`, `transcript_full.jsonl`, and one chunk file of
   each in `chunks/`.

## Mechanism

The Android Terminal app shows the shell of the VM through `ttyd`, a
web terminal. So a reader in the VM finds the terminal from the parent
chain (`ttyd`), not from the environment.

agy on aarch64 Linux keeps the same files as on x64 Linux. A reader of
agy state needs no special case for this VM.

## Incident

None.

## Screens

None.

## Not measured

- Whether the permission dialog showed in the guided steps. The files do
  not say. So item 10 does not prove that agy writes no record for a
  dialog wait.
- The `status` value in `conversation_summaries.db` during the dialog
  (fact 045). The kit saw only that the file changed.
- A permission dialog in a process that ran before the step, with no restart.
- Whether `cli.log` is a link to the newest file in `log/` or a copy.
- The `flock` lock on the presence file in this VM (fact 044).
- A Claude Code process in this VM.

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/CHANGELOG.md

# Changelog

## [0.11.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.10.0...corpus-v0.11.0) (2026-11-01)


### Features

* **probes:** show the agy summaries status and the processes after a guided step ([#67](https://github.com/xSAVIKx/agent-signals/issues/67)) ([c0078f9](https://github.com/xSAVIKx/agent-signals/commit/c0078f952d5f64421f620ffbfdfa064b7dbd5d55))

## [0.10.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.9.1...corpus-v0.10.0) (2026-11-01)


### Features

* add fact 073, agy in the Debian VM of the Android Terminal app ([#63](https://github.com/xSAVIKx/agent-signals/issues/63)) ([ce0d3bd](https://github.com/xSAVIKx/agent-signals/commit/ce0d3bdfa6c6ea59c29f32711a1b8d85b4cfa542))


### Bug Fixes

* **probes:** skip the processes that start the kit when a guided step counts agent processes ([#66](https://github.com/xSAVIKx/agent-signals/issues/66)) ([afe26ac](https://github.com/xSAVIKx/agent-signals/commit/afe26acf00d2cd92a5ed2446d91f9a967c344ade))

## [0.9.1](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.9.0...corpus-v0.9.1) (2026-11-01)


### Bug Fixes

* **probes:** find the Cursor CLI as agent in any folder, and use agent in the guided step examples ([#60](https://github.com/xSAVIKx/agent-signals/issues/60)) ([5438087](https://github.com/xSAVIKx/agent-signals/commit/543808764d9400837224a6578b15b97704a9a157))
* **probes:** list the agent processes in a guided step, watch the whole agy folder, and skip the Claude status for other agents ([#62](https://github.com/xSAVIKx/agent-signals/issues/62)) ([e9de9cd](https://github.com/xSAVIKx/agent-signals/commit/e9de9cd3d544809e59b7a9658579157d4a157a08))

## [0.9.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.8.0...corpus-v0.9.0) (2026-10-31)


### Features

* add facts 066 to 069 from the probe kit on macOS and Ubuntu ([#53](https://github.com/xSAVIKx/agent-signals/issues/53)) ([6b0a86d](https://github.com/xSAVIKx/agent-signals/commit/6b0a86de152de4286cb30cbdb2bc4198a10ac387))
* add facts 070 to 072 from the probe kit on Windows ([#55](https://github.com/xSAVIKx/agent-signals/issues/55)) ([ed1ea21](https://github.com/xSAVIKx/agent-signals/commit/ed1ea218791edbf4bd1b7d4e062c8bc559ef8270))
* **probes:** add one-line starts of the kit for macOS, Linux and Windows ([#51](https://github.com/xSAVIKx/agent-signals/issues/51)) ([71a2470](https://github.com/xSAVIKx/agent-signals/commit/71a24701049d150b58021a79ed5fa84b2a77fccd))
* **probes:** attach the probe kit to each corpus release and download it in the one-liners ([#56](https://github.com/xSAVIKx/agent-signals/issues/56)) ([2b79a8e](https://github.com/xSAVIKx/agent-signals/commit/2b79a8e4ea2544d7514d12acea16a3d1c23d85ce))
* **probes:** print procStart of each Claude pid file with the start time from ps, sysctl and /proc ([#58](https://github.com/xSAVIKx/agent-signals/issues/58)) ([af68e66](https://github.com/xSAVIKx/agent-signals/commit/af68e66e1c649bbbd4c58c5181dfe2dbd7976048))
* **site:** add llms.txt, JSON indexes and Markdown copies for agents ([#47](https://github.com/xSAVIKx/agent-signals/issues/47)) ([6b91c06](https://github.com/xSAVIKx/agent-signals/commit/6b91c06f90504c8b8ea2c22939ebf6c81f5fa383))
* **site:** add Markdown, Claude and ChatGPT actions to each page ([#49](https://github.com/xSAVIKx/agent-signals/issues/49)) ([0b98b0a](https://github.com/xSAVIKx/agent-signals/commit/0b98b0a1953f9d4db863349e7d2b5cc62538decc))


### Bug Fixes

* **probes:** accept agent as a name of Cursor and refuse unknown agents in a guided step ([#54](https://github.com/xSAVIKx/agent-signals/issues/54)) ([b6a1997](https://github.com/xSAVIKx/agent-signals/commit/b6a1997a9eb6b16f010d1ba24795e3cef1ed618a))
* **probes:** hide Windows project paths, keys and names in the probe output ([#59](https://github.com/xSAVIKx/agent-signals/issues/59)) ([75d05ca](https://github.com/xSAVIKx/agent-signals/commit/75d05ca4a9adb5e7385fc66b47363dd46045ecfe))
* **probes:** keep probe variables out of the helpers, and fix two macOS checks ([#52](https://github.com/xSAVIKx/agent-signals/issues/52)) ([8ff5cbe](https://github.com/xSAVIKx/agent-signals/commit/8ff5cbe682eadddbbaaf2e2b05b5b3a22fa8d1c5))

## [0.8.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.7.0...corpus-v0.8.0) (2026-10-31)


### Features

* **site:** add a releases page and keep the corpus release as Latest ([#43](https://github.com/xSAVIKx/agent-signals/issues/43)) ([5e716c7](https://github.com/xSAVIKx/agent-signals/commit/5e716c7ac807a3fab604cb48582c642136bced4e))


### Bug Fixes

* **site:** keep tables and the navigation inside the screen, and put who and how first in the README ([#45](https://github.com/xSAVIKx/agent-signals/issues/45)) ([420ed0b](https://github.com/xSAVIKx/agent-signals/commit/420ed0b93a941b1a3e73748a1c8a8cb42ffb94b3))

## [0.7.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.6.0...corpus-v0.7.0) (2026-10-31)


### Features

* add 14 agents, a CODEX_HOME run and more Windows agents to the first-run CI ([#41](https://github.com/xSAVIKx/agent-signals/issues/41)) ([f0637e8](https://github.com/xSAVIKx/agent-signals/commit/f0637e8b2ebf7b5812e9db40b19e6b16ebb30bf6))
* **python:** add a Python library that loads the corpus ([#39](https://github.com/xSAVIKx/agent-signals/issues/39)) ([e655ac3](https://github.com/xSAVIKx/agent-signals/commit/e655ac378443f814e2bdfea4ad3a028028901dc2))

## [0.6.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.5.0...corpus-v0.6.0) (2026-10-31)


### Features

* add a ConPTY driver and a first-run scenario for Windows ([#37](https://github.com/xSAVIKx/agent-signals/issues/37)) ([5452c4b](https://github.com/xSAVIKx/agent-signals/commit/5452c4b261d778ce16b2bb3e597a744981fbdb2c))
* add the first screens of 16 more agents with no login ([#34](https://github.com/xSAVIKx/agent-signals/issues/34)) ([cf0649d](https://github.com/xSAVIKx/agent-signals/commit/cf0649d77573c58c052cea25db102d57ab1557a6))

## [0.5.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.4.0...corpus-v0.5.0) (2026-10-30)


### Features

* add Codex scenarios for a denial, interrupts, hooks and the daemon ([#30](https://github.com/xSAVIKx/agent-signals/issues/30)) ([7b6440e](https://github.com/xSAVIKx/agent-signals/commit/7b6440e690b8aeedbe294f0c8cc54545627194b3))
* add facts 031 to 035, more Claude Code waits and a resume ([#27](https://github.com/xSAVIKx/agent-signals/issues/27)) ([ca5740d](https://github.com/xSAVIKx/agent-signals/commit/ca5740d9a06ea49fac27bd4bd5d5c74686f46b9e))
* add the documentation website ([#28](https://github.com/xSAVIKx/agent-signals/issues/28)) ([3aa17bb](https://github.com/xSAVIKx/agent-signals/commit/3aa17bba1199a6774381de2fe73fc5312816310d))
* measure more agy 1.4.7 signals (facts 041 to 045) ([#26](https://github.com/xSAVIKx/agent-signals/issues/26)) ([5922f5a](https://github.com/xSAVIKx/agent-signals/commit/5922f5aa527bf72b8532b3f16aac503e4aebccf4))
* run the probes and scenarios on each free runner image, with facts 046 to 050 ([#25](https://github.com/xSAVIKx/agent-signals/issues/25)) ([793ee1b](https://github.com/xSAVIKx/agent-signals/commit/793ee1b7f7e3069fd6eb9f703afba2f845b37ddb))


### Bug Fixes

* keep version numbers out of the IP rule of the scrub ([#33](https://github.com/xSAVIKx/agent-signals/issues/33)) ([94fa3f5](https://github.com/xSAVIKx/agent-signals/commit/94fa3f5e8322cf7ebfa9cb5be9980325b2090316))

## [0.4.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.3.0...corpus-v0.4.0) (2026-10-30)


### Features

* add fact 030, the first start of four more agents ([#22](https://github.com/xSAVIKx/agent-signals/issues/22)) ([78bff0c](https://github.com/xSAVIKx/agent-signals/commit/78bff0c8277aa2fd560249ce923dc762f4a38b80))
* add the Copilot CLI and Gemini CLI probes for Linux and macOS ([#24](https://github.com/xSAVIKx/agent-signals/issues/24)) ([be4d524](https://github.com/xSAVIKx/agent-signals/commit/be4d524df1a1d0229e2e0ffc67c462723fd3fc7e))

## [0.3.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.2.0...corpus-v0.3.0) (2026-10-30)


### Features

* add Codex CLI 0.164.0 screens: idle, busy and the F2 Warnings view ([#17](https://github.com/xSAVIKx/agent-signals/issues/17)) ([de64562](https://github.com/xSAVIKx/agent-signals/commit/de64562ed2dea71c29efce58e5e6b15b89855c99))
* add fact 029, the first start of each agent with no login ([#20](https://github.com/xSAVIKx/agent-signals/issues/20)) ([4035d26](https://github.com/xSAVIKx/agent-signals/commit/4035d26b9e3da68be2695905bd0b776d325e9732))
* add the agy turn scenario and its fact ([#14](https://github.com/xSAVIKx/agent-signals/issues/14)) ([fa47abe](https://github.com/xSAVIKx/agent-signals/commit/fa47abe591c95ed9c75c4aa376310e33e500b70b))
* add the Claude permission scenario and its facts ([#12](https://github.com/xSAVIKx/agent-signals/issues/12)) ([c14c386](https://github.com/xSAVIKx/agent-signals/commit/c14c386494cb142dff5336c1a7b7c4c1d3e16731))
* add the Codex approval scenarios and their facts ([#13](https://github.com/xSAVIKx/agent-signals/issues/13)) ([0d336bd](https://github.com/xSAVIKx/agent-signals/commit/0d336bd2d0dd37a79d84ce6d42c9c69d67165181))
* add the Cursor CLI macOS probe and its first facts ([#8](https://github.com/xSAVIKx/agent-signals/issues/8)) ([1e7c981](https://github.com/xSAVIKx/agent-signals/commit/1e7c9810af5ea107868fe4691218191dd4bc4946))
* add the first-run scenario and the scenarios workflow ([#19](https://github.com/xSAVIKx/agent-signals/issues/19)) ([56e15b0](https://github.com/xSAVIKx/agent-signals/commit/56e15b0e5ee705795bdb28af1079835d8b746821))
* add the probes, the kit and the scrub for Linux and macOS ([#15](https://github.com/xSAVIKx/agent-signals/issues/15)) ([bfed8ab](https://github.com/xSAVIKx/agent-signals/commit/bfed8ab699548479b7dc74d00dc42e3f6f604f21))
* add the Windows probes, the Windows kit and the PowerShell scrub ([#16](https://github.com/xSAVIKx/agent-signals/issues/16)) ([b674c03](https://github.com/xSAVIKx/agent-signals/commit/b674c0383c636c8b40139027cdef545b74d1c6d6))

## [0.2.0](https://github.com/xSAVIKx/agent-signals/compare/corpus-v0.1.0...corpus-v0.2.0) (2026-10-24)


### Features

* add Codex CLI 0.163.0 screens and facts ([#5](https://github.com/xSAVIKx/agent-signals/issues/5)) ([3f65f0c](https://github.com/xSAVIKx/agent-signals/commit/3f65f0cdb7a84f7b8c61c6b67951219f7f9ffd06))
* **go:** add a Go library that loads the corpus ([#4](https://github.com/xSAVIKx/agent-signals/issues/4)) ([b033130](https://github.com/xSAVIKx/agent-signals/commit/b03313074f9b92e174053c8a7e6b34710e1b2d7d))

## 0.1.0 (2026-10-24)


### Features

* seed the corpus with the tg-bridge screens and facts ([#1](https://github.com/xSAVIKx/agent-signals/issues/1)) ([132edd3](https://github.com/xSAVIKx/agent-signals/commit/132edd34ff7e68b7b8ff15d5c16c21d8f1f0d992))

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/go/CHANGELOG.md

# Changelog

## [0.9.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.8.0...go/v0.9.0) (2026-11-01)


### Features

* **probes:** show the agy summaries status and the processes after a guided step ([#67](https://github.com/xSAVIKx/agent-signals/issues/67)) ([c0078f9](https://github.com/xSAVIKx/agent-signals/commit/c0078f952d5f64421f620ffbfdfa064b7dbd5d55))

## [0.8.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.7.0...go/v0.8.0) (2026-11-01)


### Features

* add fact 073, agy in the Debian VM of the Android Terminal app ([#63](https://github.com/xSAVIKx/agent-signals/issues/63)) ([ce0d3bd](https://github.com/xSAVIKx/agent-signals/commit/ce0d3bdfa6c6ea59c29f32711a1b8d85b4cfa542))


### Bug Fixes

* **probes:** skip the processes that start the kit when a guided step counts agent processes ([#66](https://github.com/xSAVIKx/agent-signals/issues/66)) ([afe26ac](https://github.com/xSAVIKx/agent-signals/commit/afe26acf00d2cd92a5ed2446d91f9a967c344ade))

## [0.7.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.6.0...go/v0.7.0) (2026-10-31)


### Features

* add facts 066 to 069 from the probe kit on macOS and Ubuntu ([#53](https://github.com/xSAVIKx/agent-signals/issues/53)) ([6b0a86d](https://github.com/xSAVIKx/agent-signals/commit/6b0a86de152de4286cb30cbdb2bc4198a10ac387))
* add facts 070 to 072 from the probe kit on Windows ([#55](https://github.com/xSAVIKx/agent-signals/issues/55)) ([ed1ea21](https://github.com/xSAVIKx/agent-signals/commit/ed1ea218791edbf4bd1b7d4e062c8bc559ef8270))

## [0.6.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.5.0...go/v0.6.0) (2026-10-31)


### Features

* add 14 agents, a CODEX_HOME run and more Windows agents to the first-run CI ([#41](https://github.com/xSAVIKx/agent-signals/issues/41)) ([f0637e8](https://github.com/xSAVIKx/agent-signals/commit/f0637e8b2ebf7b5812e9db40b19e6b16ebb30bf6))

## [0.5.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.4.0...go/v0.5.0) (2026-10-31)


### Features

* add a ConPTY driver and a first-run scenario for Windows ([#37](https://github.com/xSAVIKx/agent-signals/issues/37)) ([5452c4b](https://github.com/xSAVIKx/agent-signals/commit/5452c4b261d778ce16b2bb3e597a744981fbdb2c))
* add the first screens of 16 more agents with no login ([#34](https://github.com/xSAVIKx/agent-signals/issues/34)) ([cf0649d](https://github.com/xSAVIKx/agent-signals/commit/cf0649d77573c58c052cea25db102d57ab1557a6))

## [0.4.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.3.0...go/v0.4.0) (2026-10-30)


### Features

* add Codex scenarios for a denial, interrupts, hooks and the daemon ([#30](https://github.com/xSAVIKx/agent-signals/issues/30)) ([7b6440e](https://github.com/xSAVIKx/agent-signals/commit/7b6440e690b8aeedbe294f0c8cc54545627194b3))
* add facts 031 to 035, more Claude Code waits and a resume ([#27](https://github.com/xSAVIKx/agent-signals/issues/27)) ([ca5740d](https://github.com/xSAVIKx/agent-signals/commit/ca5740d9a06ea49fac27bd4bd5d5c74686f46b9e))
* measure more agy 1.4.7 signals (facts 041 to 045) ([#26](https://github.com/xSAVIKx/agent-signals/issues/26)) ([5922f5a](https://github.com/xSAVIKx/agent-signals/commit/5922f5aa527bf72b8532b3f16aac503e4aebccf4))
* run the probes and scenarios on each free runner image, with facts 046 to 050 ([#25](https://github.com/xSAVIKx/agent-signals/issues/25)) ([793ee1b](https://github.com/xSAVIKx/agent-signals/commit/793ee1b7f7e3069fd6eb9f703afba2f845b37ddb))


### Bug Fixes

* keep version numbers out of the IP rule of the scrub ([#33](https://github.com/xSAVIKx/agent-signals/issues/33)) ([94fa3f5](https://github.com/xSAVIKx/agent-signals/commit/94fa3f5e8322cf7ebfa9cb5be9980325b2090316))

## [0.3.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.2.0...go/v0.3.0) (2026-10-30)


### Features

* add fact 030, the first start of four more agents ([#22](https://github.com/xSAVIKx/agent-signals/issues/22)) ([78bff0c](https://github.com/xSAVIKx/agent-signals/commit/78bff0c8277aa2fd560249ce923dc762f4a38b80))

## [0.2.0](https://github.com/xSAVIKx/agent-signals/compare/go/v0.1.0...go/v0.2.0) (2026-10-30)


### Features

* add Codex CLI 0.164.0 screens: idle, busy and the F2 Warnings view ([#17](https://github.com/xSAVIKx/agent-signals/issues/17)) ([de64562](https://github.com/xSAVIKx/agent-signals/commit/de64562ed2dea71c29efce58e5e6b15b89855c99))
* add fact 029, the first start of each agent with no login ([#20](https://github.com/xSAVIKx/agent-signals/issues/20)) ([4035d26](https://github.com/xSAVIKx/agent-signals/commit/4035d26b9e3da68be2695905bd0b776d325e9732))
* add the agy turn scenario and its fact ([#14](https://github.com/xSAVIKx/agent-signals/issues/14)) ([fa47abe](https://github.com/xSAVIKx/agent-signals/commit/fa47abe591c95ed9c75c4aa376310e33e500b70b))
* add the Claude permission scenario and its facts ([#12](https://github.com/xSAVIKx/agent-signals/issues/12)) ([c14c386](https://github.com/xSAVIKx/agent-signals/commit/c14c386494cb142dff5336c1a7b7c4c1d3e16731))
* add the Codex approval scenarios and their facts ([#13](https://github.com/xSAVIKx/agent-signals/issues/13)) ([0d336bd](https://github.com/xSAVIKx/agent-signals/commit/0d336bd2d0dd37a79d84ce6d42c9c69d67165181))
* add the Cursor CLI macOS probe and its first facts ([#8](https://github.com/xSAVIKx/agent-signals/issues/8)) ([1e7c981](https://github.com/xSAVIKx/agent-signals/commit/1e7c9810af5ea107868fe4691218191dd4bc4946))

## 0.1.0 (2026-10-24)


### Features

* add Codex CLI 0.163.0 screens and facts ([#5](https://github.com/xSAVIKx/agent-signals/issues/5)) ([3f65f0c](https://github.com/xSAVIKx/agent-signals/commit/3f65f0cdb7a84f7b8c61c6b67951219f7f9ffd06))
* **go:** add a Go library that loads the corpus ([#4](https://github.com/xSAVIKx/agent-signals/issues/4)) ([b033130](https://github.com/xSAVIKx/agent-signals/commit/b03313074f9b92e174053c8a7e6b34710e1b2d7d))

---

Source: https://github.com/xSAVIKx/agent-signals/blob/main/python/CHANGELOG.md

# Changelog

## [0.4.0](https://github.com/xSAVIKx/agent-signals/compare/python-v0.3.0...python-v0.4.0) (2026-11-01)


### Features

* **probes:** show the agy summaries status and the processes after a guided step ([#67](https://github.com/xSAVIKx/agent-signals/issues/67)) ([c0078f9](https://github.com/xSAVIKx/agent-signals/commit/c0078f952d5f64421f620ffbfdfa064b7dbd5d55))

## [0.3.0](https://github.com/xSAVIKx/agent-signals/compare/python-v0.2.0...python-v0.3.0) (2026-11-01)


### Features

* add fact 073, agy in the Debian VM of the Android Terminal app ([#63](https://github.com/xSAVIKx/agent-signals/issues/63)) ([ce0d3bd](https://github.com/xSAVIKx/agent-signals/commit/ce0d3bdfa6c6ea59c29f32711a1b8d85b4cfa542))


### Bug Fixes

* **probes:** skip the processes that start the kit when a guided step counts agent processes ([#66](https://github.com/xSAVIKx/agent-signals/issues/66)) ([afe26ac](https://github.com/xSAVIKx/agent-signals/commit/afe26acf00d2cd92a5ed2446d91f9a967c344ade))

## [0.2.0](https://github.com/xSAVIKx/agent-signals/compare/python-v0.1.0...python-v0.2.0) (2026-10-31)


### Features

* add facts 066 to 069 from the probe kit on macOS and Ubuntu ([#53](https://github.com/xSAVIKx/agent-signals/issues/53)) ([6b0a86d](https://github.com/xSAVIKx/agent-signals/commit/6b0a86de152de4286cb30cbdb2bc4198a10ac387))
* add facts 070 to 072 from the probe kit on Windows ([#55](https://github.com/xSAVIKx/agent-signals/issues/55)) ([ed1ea21](https://github.com/xSAVIKx/agent-signals/commit/ed1ea218791edbf4bd1b7d4e062c8bc559ef8270))

## 0.1.0 (2026-10-31)


### Features

* add 14 agents, a CODEX_HOME run and more Windows agents to the first-run CI ([#41](https://github.com/xSAVIKx/agent-signals/issues/41)) ([f0637e8](https://github.com/xSAVIKx/agent-signals/commit/f0637e8b2ebf7b5812e9db40b19e6b16ebb30bf6))
* **python:** add a Python library that loads the corpus ([#39](https://github.com/xSAVIKx/agent-signals/issues/39)) ([e655ac3](https://github.com/xSAVIKx/agent-signals/commit/e655ac378443f814e2bdfea4ad3a028028901dc2))