Detect Otto and GitHub Copilot as calling agents

[jlaneve]

_detect_invocation_context reads a fixed list of environment variables to work out which coding agent ran the command. Otto is not on it and sets no marker of its own, so every af command Otto runs arrives with no agent and looks like a person typing.

This matters more for af than for astro. Otto installs its own pinned af wrapper and puts it first on PATH, so in an Otto session essentially all af traffic is Otto-driven — and none of it is labelled.

There is a second effect. Otto hands its environment to child processes untouched, so a user who starts Otto from inside another coding agent passes that agent's variable straight through to af, and the commands get credited to it. Some share of the claude-code volume in af telemetry is really Otto.

What this does

Adds "OTTO": "otto" to agent_env_vars, first in the dict. The loop breaks on the first match and dicts keep insertion order, so position is the fix for the second problem: with OTTO ahead of CLAUDECODE, an Otto session started inside Claude Code reports otto, the nearer caller.

Companion changes: astronomer/otto#379 sets OTTO=1; astronomer/astro-cli#2234 and astronomer/astro-cli-internal#81 do the same for the astro CLI. Until the Otto change ships this is inert.

Testing

test_detects_otto and test_otto_wins_over_inherited_marker, plus OTTO added to the clean_env fixture so it cannot leak in from the environment running the suite. 45 tests pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NKSW26NfBtfq8hVeeLdfLj

Update: also adds GitHub Copilot detection

Second commit on this branch. Copilot was missing from the same list, so anything run from Copilot arrived unlabelled too.

Variable	Surface	Source
COPILOT_CLI	Copilot CLI — also the harness behind the cloud coding agent and, since 2026, Copilot for JetBrains	github's own gh keys on it: cli/cli internal/agents/detect.go
COPILOT_AGENT	VS Code agent mode terminals	microsoft/vscode toolTerminalCreator.ts, where it is commented as backward compatibility for this kind of detection
AI_AGENT	VS Code agent mode (github_copilot_vscode_agent), Copilot desktop app (github_copilot_app_agent)	microsoft/vscode aiAgentEnv.ts, which calls it a wire contract

AI_AGENT is a different shape from everything else in the list: the value names the agent, not the variable. It is read after the list so a specific marker still decides, and only prefixes we recognise are mapped.

Values are deliberately not passed through, which is where this differs from gh. gh returns any value matching ^[a-zA-Z0-9_-]+$. Some vendors put a version in theirs — Claude Code's is claude-code_2-1-156_agent — so passing values through would spread one agent across a new telemetry value on every release and make the column useless for grouping. A new vendor adopting the convention is a one-line addition.

Two candidates dropped after checking the sources

COPILOT_AGENT_SESSION_ID is widely cited but appears in no Copilot CLI changelog entry through 1.0.76, and gh does not read it. COPILOT_CLI covers the same surface with a first-party source behind it.

VSCODE_AGENT is named in the VS Code 1.121 release notes but does not exist in the source — only VSCODE_AGENT_ZSH_FIXUPS and VSCODE_AGENT_HOST_*. The release note is wrong and at least one other library has copied the error.

Also avoided: COPILOT_MODEL, COPILOT_ALLOW_ALL, COPILOT_GITHUB_TOKEN. Some detectors key on these, but they are user config the CLI reads, so anyone with export COPILOT_MODEL=… in a shell profile would be misdetected forever.

Worth a follow-up, not in this PR

CODEX_API_KEY in the existing list has that same flaw — it is a key the user sets, not a marker Codex exports. CODEX_THREAD_ID or CODEX_SANDBOX are what Codex actually sets per execution, and are what gh reads.

[jlaneve]

The Type checking job failure here is pre-existing and unrelated to this PR.

It fails on skills/analyzing-data/scripts/cli.py — Cannot resolve imported module click`` — a file this branch does not touch. This PR changes only astro-airflow-mcp/src/astro_airflow_mcp/telemetry.py and its test.

I reproduced it on an untouched checkout of current origin/main, same error:

error[unresolved-import]: Cannot resolve imported module `click`
  --> cli.py:26:8

The cause is the job itself. .github/workflows/ci.yml:85-96 runs uvx ty check in skills/analyzing-data/scripts with no dependency install step, so click is only ever resolvable by accident, and ty is unpinned so every run picks up the latest release. Main looks green because its last run was 2026-07-20, before the ty version that reports this.

Two ways to fix, whichever the owners prefer: run it as uv run ty check (or add a uv sync step) so the project's own dependencies are on the path, or pin ty so the workflow stops drifting. Happy to open a separate PR for that — it touches a shared workflow, so it did not belong in this one.