Which agent for which job, and the handoff you still do by hand

Claude Code: the handoff surfaces are the PR and the background agent

There are two flags in Claude Code which are actually more like ways of passing work between people (or machines), rather than features you use during a session.

The first one is --from-pr — this allows you to either pass a number or URL of a PR and resume a session connected with it (so the session has an address that points to the PR, not some random UUID), or launch the interactive mode and choose the PR from a list (with an option of searching for a PR by typing a search term). This is useful because you can point to a PR (that's something your colleague probably knows about) rather than some UUID (which they don't).

The second one is --bg (or --background), which allows you to run a session as a background process and immediately get back control. Behind the scenes, it creates an agent in claude agents which is how you can manage it. This is useful for running long-running processes without giving up your terminal (and without using a cloud runner).

Another thing that's useful to know if you plan to use multiple agents within a single repository is the --worktree flag (or -w). It tells git to create a worktree for the session, so you can have two sessions using Claude Code in a single repository and they won't collide.

The memory file trap. Last but not least, if you're a part of a team that uses multiple tools, you should be aware of the "memory file trap". This is the worst kind of a trap. Basically, it's because Claude Code reads CLAUDE.md (not AGENTS.md), and the Claude Code docs say it plainly: "Claude Code reads CLAUDE.md, not AGENTS.md. If your repository already uses AGENTS.md for other coding agents, create a CLAUDE.md that imports it so both tools read the same instructions without duplicating them." So you can either create a symbolic link from CLAUDE.md to AGENTS.md:

ln -s AGENTS.md CLAUDE.md

or you can prepend the following line to CLAUDE.md:

@AGENTS.md

## Claude Code

Use plan mode for changes under `src/billing/`.

We'd recommend the import one on a team, as it leaves you a place in CLAUDE.md for the Claude-specific instructions (like "use plan mode for changes under src/billing/") which shouldn't land in everyone else's context. If you're on Windows, you'll need to be an admin or enable developer mode to create symlinks so in that case you should go with import.

The last thing we'd like to mention is that /init has already been "stealing" some best practices from other tools to include them in CLAUDE.md by default — for example:

• cursor rules (from .cursor/rules or .cursorrules)

• copilot rules (from .github/copilot-instructions.md)

And actually, if you set the env var CLAUDE_CODE_NEW_INIT=1 and run /init, it will also read:

• AGENTS.md

• .devin/rules/

• .windsurf/rules or .windsurfrules

• .clinerules

So if you join a repo that has been set up for another tool, instead of creating an empty CLAUDE.md from scratch, you get a more sensible starting point.

What we ran. We've also tested:

• Claude Code 2.1.221 on macOS

• Made a session using --session-id and resumed it using --resume

• Resuming with --resume and a UUID of 00000000-0000-4000-8000-000000000000 results in exit code 1 and message "No conversation found with session ID"

• The flags' descriptions are from claude --help, the memory-file thing is from the Claude Code docs (checked today, 2026-08-05)

Codex: the handoff is a diff, not a session

It's important to understand that the unit of transfer in Codex is a patch, not a chat log. Thanks to that, it's possible to move work itself in Codex, not only a record of a conversation about work.

Using the codex apply <TASK_ID> command you can pull the most recent changes from a Codex agent into your local working tree using git apply. In other words, when you use this command, the remote task lands as a regular diff in your working tree so you can review it with any tool you're used to, and so can a colleague who's never seen Codex.

codex apply <TASK_ID>

If you want to explore the tasks in the Codex Cloud, you can use the experimental codex cloud command. It allows you to apply changes from the tasks in the cloud locally.

Thanks to these two commands, working with Codex feels like sending work files between each other rather than a chat log.

Another useful command for teams using multiple tools is codex mcp-server, which starts Codex as an MCP server listening on stdio. This way, you can make Codex a tool that another agent can call. It's not a session handover, so sometimes it might even make sense to combine these two approaches and create a session in which there's another session.

Sessions.

• Resuming a session is possible with the codex resume command, which accepts either a session UUID or its name, but by default falls back to an interactive picker. If you want to see all sessions, not only those connected with the current working directory, you can add the --all flag (in this mode, the CWD filter is disabled and an additional column called "CWD" appears in the picker)

• To split a branch from an existing session, you can use codex fork. Just like with resuming, this command falls back to the interactive picker by default

• There are more commands connected with the session's lifecycle, like codex archive, codex delete or codex unarchive

The session ID doesn't need to be hunted down, as a headless invocation prints a startup banner (with the ID in it) before actually doing anything:

$ codex exec "Reply with the single word ok."
OpenAI Codex v0.146.0
--------
workdir: /private/tmp/waw-check
model: gpt-5.6-terra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 019fd0c8-2ef8-7912-be1e-cd06db8121ab
--------

As you can see, it contains the session's ID as well as a description of the context in which the run was started (version, working directory, model, provider, approval mode, sandbox state, reasoning effort and summaries state).

The session's ID is especially valuable, as thanks to it, you can resume the session at any point. At the same time, the context is a piece of information that's always useful to have in a CI log.

The gotcha. Resuming a session is a TUI feature though, so if you try to run codex resume without a tty on stdin, it will throw an error:

$ codex resume <id>
Error: stdin is not a terminal

The headless equivalent of this command lives under the exec namespace and can be called as codex exec resume <session-id> "<prompt>":

codex exec resume <session-id> "carry on with the migration"

If you decide to use the session ID from another tool, it won't work either — you'll get Error: thread/resume: thread/resume failed: no rollout found for thread id … (code -32600), which means that there's no session with such an ID in Codex's own store, and its exit status is 1, which is the proper behaviour when it comes to scripts.

What we ran. These are the commands we've actually used, except for apply and cloud as they want an existing task in the cloud:

• codex resume (from a non-tty)

• codex exec "Reply with the single word ok." (to get the banner)

• codex exec resume <a session id from another tool> (to try and resume somebody else's)

• --help for: codex, exec, resume, apply, fork

Copilot: the one that exports, and the one you already pay for

Copilot is great for route decisions more often than you might think; two reasons for that:

It exports sessions as a human-readable markdown. Compared to other tools, only Kimi Code also supports it, but what's important, it exports everything as ZIP files, while Copilot allows you to copy the result and share it as a single command with a PR comment for example.

copilot -p "…" --share

For instance, using --share-gist, it can post the session to a secret GitHub gist, or using --remote-export to GitHub web or mobile in a read-only mode (no remote control), but still, nothing of these is a file another agent can eat; but dropping that markdown into a PR comment is a handoff, done with a single command.

It has the GitHub MCP server pre-installed. It's called github-mcp-server if you check --disable-builtin-mcps. What's more, in most of the teams there's already a seat booked, so naturally, it can route any GitHub-related work.

It utilises skills defined for other tools; if your team is mixed, it's probably the most important takeaway. You can drop a marker skill into each directory convention and list it like this:

$ copilot skill list
Project skills:
  from-github-dir - Marker skill placed in .github/skills to see who discovers it.
  from-agents-dir - Marker skill placed in .agents/skills to see who discovers it.
  from-claude-dir - Marker skill placed in .claude/skills to see who discovers it.

If you have a look at the help, it says the project skills are from these 3 directories, and for your personal ones, there's either ~/.copilot/skills/ or ~/.agents/skills/ directory, so if you're using Claude Code, one of your teammate's Claude Code skill might already work in Copilot. Before creating a new skill, make sure to list them first.

It also consumes AGENTS.md and related files (see --no-custom-instructions) and workspace-level MCP config from .mcp.json or .github/mcp.json files (the former is actually in Claude Code's help as well).

Finally, it can resume sessions using session ids, task ids, id prefixes or names — the most flexible way to address a session compared to other tools. What's more, if you set your own name using --name, it's much easier to communicate than UUID; if you use an unknown id, it will exit with code 1 and list all ways you can address sessions.

What we ran. Using GitHub Copilot CLI v1.0.78 on macOS. Skill listing run in a throwaway repository with all three skill conventions. Resume with an id from another tool (exited with code 1). --share, --share-gist and --remote-export are quoted from copilot --help, we didn't exercise them.

Cursor: chat ids you can mint in advance, and a trust gate to plan around

The most distinctive feature of Cursor's CLI is that it can pre-allocate a session container before you actually run anything and enforces a certain routing thanks to a permission gate. One of the capabilities it has is a subcommand that creates an empty chat and returns its ID.

agent create-chat        # "Create a new empty chat and return its ID"

Thanks to this, you can easily share the ID with your teammates or include it in a ticket or a script before doing any work. The ID is also a thing that other Cursor CLI commands consume. For example, --resume accepts a chat ID, agent ls and agent resume are documented as resuming a chat session, and ls allows you to pick one while resume takes the most recent one. In terms of the competition, both Claude Code and Copilot provide ways to pin a session UUID in advance via --session-id parameter but it's the user who is responsible for generating the value there. Cursor is the only one here that pre-generates an ID and provides it out of the box without actually needing to run anything.

Another capability is the worker subcommand which starts a private cloud worker connected with Cursor that runs agents within your environment. Perfect for cases when you need to run things on your machine, not on a third party's cloud.

The last one is -w/--worktree [name] which runs a session in an isolated worktree under ~/.cursor/worktrees/<reponame>/<name>, and the --worktree-base <branch> parameter allows you to select a fork point.

The gotcha, and it's the one that decides routing. Now let's think about the problem that we're facing here. Before anything, Cursor runs a per-directory trust check — before model selection, before session ID handling etc. During this check, the following prompt is being displayed:

⚠ Workspace Trust Required

  Cursor Agent can execute code and access files in this directory.
  Do you trust the contents of this directory?

As you can see, it says that Cursor Agent will be able to run code and access files in this directory and asks if you're sure if you trust files in this directory. When we tried to run agent --resume with an ID from another tool in a fresh temp repo, we've seen it and the process has been terminated with code 1. It was obvious that the ID wasn't examined in this scenario. That means that when you run a CI job, the directory is always new so you need to somehow get rid of this check if you want to make your pipeline automated. The prompt offers three solutions: --trust which is bound only to the directory, and -f/--force (also aliased as --yolo) which is described as allowing every command unless explicitly denied. The latter seems like a good option but it also allows everything so generally speaking you might want to go for --trust.

Also, if you look at the help, you'll notice that -p/--print is described as having every tool available, including write and shell. We assume it means that in print mode, Cursor gives you access to write and shell without asking for a permission (that's opposite to Codex which by default operates in read-only mode and displays it in its banner). That'd be very important to know if we were to choose between these tools for an automated pipeline.

This is actually not something we've observed. What we've seen is that when you run the agent with an ID inside an untrusted directory, it asks about the trust first. And as it didn't examine the ID, it must be that the trust check happens before any of the other steps.

The last thing is that MCP configuration is read from .cursor/mcp.json (or ~/.cursor/mcp.json) as part of agent mcp login.

What we ran. We've been testing this using: cursor-agent version 2026.07.23-e383d2b, macOS. Tried to pass a chat ID from another tool to --resume inside an untrusted temp repo and hit the trust gate with exit code 1. Due to that, we couldn't check if the ID was processed at all. As the directory wasn't trusted, the rest of the process wasn't run either. Print-mode tool-access part is a piece of information from the help rather than our observations. Other details from agent --help and subcommands' help.

Antigravity: check that it knows which conversation it's in

Only one of the harnesses from the comparison group silently accepts a session id from somewhere else and doesn't throw an error; for example:

$ agy --conversation 7c9e6a1b-4f2d-4a3e-9b81-0d5c2f8e1a70 \
    -p "Which deploy target did we pick, and why? One sentence."

The command above returns:

We have not selected a deployment target yet in our session, so please let me know which target
options or project you are referring to.

We passed a session id of a Claude Code session and therefore it doesn't exist here, but instead of throwing, Antigravity started a new conversation and responded that there's no context.

Let's try it again:

$ agy --conversation 7c9e6a1b-4f2d-4a3e-9b81-0d5c2f8e1a70 \
    -p "Which deploy target did we pick, and why? One sentence."

And it returns a different shape of nothing (a read_file auto-denial). The exit code is 0 in both cases too; for the rest of the harnesses from the comparison group it's 1 if an id is unknown.

So it doesn't make sense to check the exit code of --conversation in scripts — if previous context matters you should assert on the output anyway.

Its own handles. Antigravity-specific flags that are connected with sessions and resuming:

• --conversation — resumes a specific conversation id

• -c / --continue — continues the last one

• --project — sets "Project ID for the current CLI session"

• --new-project — creates a new project; which is an additional layer above conversations, not available as a session flag in any of the other tools

There's a separate SQLite file per conversation stored under ~/.gemini/antigravity-cli/conversations and there's also a conversation_summaries.db file in this directory.

Worth mentioning that it has a --json-schema flag too — "Optional JSON schema string or path to a schema file to enforce structured output (for stream-json, only applicable to the final result)". Whenever you use some tool to power another program rather than a human, it's better to standardise the output's structure there instead of parsing texts later on.

What we ran. Antigravity CLI 1.1.10, macOS, a disposable git repo under /tmp, no permission flags:

agy --conversation <an id from another tool> -p "…"

Twice, exit code 0 both times. The flag descriptions are from agy --help.

Kimi Code: the export is a ZIP, and the resume flag it prints isn't the one in the help

The latest version of Kimi Code exports the current session to ZIP when using the export subcommand, if you don't provide a session ID it falls back to the latest one, also by default it includes the global diagnostic log from ~/.kimi-code/logs/kimi-code.log which is worth knowing when you attach the output to a ticket. You can exclude it with the --no-include-global-log flag. There's also a browser-based visualiser for sessions (kimi vis [session ID]) and a local web UI (kimi web).

kimi export [sessionId] -o handoff.zip

There's also kimi acp, which exposes it as an Agent Client Protocol server on stdio so ACP editors can connect to it and control the agent — that way they can drive the agent from the editor, but they don't import another person's session.

The gotcha. Looking at the resume command, we can see there's a resume instruction printed in the end-of-run message using -r and the session ID.

To resume this session: kimi -r session_ac2c5d8d-f45e-4d3e-92d0-c85025aaf3d0

On the other hand, as per the help on 0.31.1 version, the tool supports only -S/--session [id] and -c/--continue

We checked that -r is indeed a valid flag (it shows an error about the session when we pass it an invalid ID, instead of saying that it doesn't know such flag) so it's best to use -S in scripts as it appears there

Sessions are stored per workspace under ~/.kimi-code/sessions/wd_<workspace>_<hash>/ and the index file is under ~/.kimi-code/session_index.jsonl. If you provide a session ID from another tool you'll get code 1 with a message saying that the session wasn't found

It reads AGENTS.md. In terms of the AGENTS.md thing, we have seen the tool refer to it without us naming the file in the prompt during our handoff test. We've noticed it mentions the deploy target but doesn't say why. And then it refers to this note:

The deploy target is `staging-7`. It was chosen because `staging-3` is pinned to an old runtime
(and can't be bumped, since its image is shared with other teams) while `staging-9` has no
database attached.

This tool hasn't been involved in the original session so the entire process of using the file for handoff worked end-to-end in this tool.

What we ran. We were testing Kimi Code CLI 0.31.1 (the rewritten native binary from ~/.kimi-code/bin, with its own config directory and a migrate subcommand to migrate an older Python-based kimi-cli, which is a separate package) in two runs of kimi -p in a throwaway git repo under /tmp and in one run of kimi -S with an ID from another tool and one of kimi -r with an invalid ID. The flag descriptions were taken from kimi --help and kimi export --help