A coding agent you can leave and return to: trying spore here

Run a bounded coding task in a Git project, inspect its changes, and return to the same agent without treating the conversation as the only artifact.

In the first article, a Spore agent built a Godot game, wrote bots to test it and revised it after a second prompt.

You don't need a game-sized task to try the same runtime. spore here opens a coding agent in a Git repository. It works on the files in place, runs commands and returns to the same conversation when you reopen it.

This article is a small, documented first-use workflow—not another recorded experiment. The suggested task below is yours to run; it isn't a claim that every model will complete it correctly.

I'm the creator of Spore, an Apache-2.0 runtime for persistent AI agents.

Start with a small project, not your most sensitive repository

Use a disposable clone of a project you understand, ideally one with a working test command. Start with a clean working tree so changes are easy to attribute.

Don't include credentials, confidential documents or production configuration in this first experiment. The agent has network access by default. Confinement doesn't prevent it from sending material it is allowed to read.

The agent can read and change the project you grant it. That's the point of the workflow, but also a reason to choose the project deliberately.

Set up the runtime

Agents execute on Linux, x64 or arm64. Current requirements include:

• Node 24+ with bundled SQLite 3.51.3 or newer;
• Linux 5.13+ with Landlock enabled; 6.12+ is recommended for additional isolation features;
• unprivileged user namespaces;
• supported model access.

On macOS, setup uses a Lima Linux VM. On Windows, run the Linux workflow in WSL2. The installation guide covers platform-specific steps; don't assume each host has identical confinement features.

For Bash on a supported Linux host, or inside WSL2 with the prerequisites installed:

cd "$HOME" npm install -g @rhizogrip/spore-cli spore setup spore doctor 

The install line changes the global npm installation. Setup writes configuration and connects model access; subsequent agent work may incur provider charges or consume subscription allowances.

Setup offers recommended models passing Spore's core and identity conformance tiers. That's more useful than selecting a model solely because it appears in a provider's catalog, but it isn't a guarantee that a model will solve your task or that your account can access it.

On Ubuntu, namespace restrictions may require an AppArmor adjustment. Read the specific instructions setup prints rather than disabling host restrictions indiscriminately. spore doctor reports host prerequisites and exercises boundaries; treat warnings as information to resolve, not decoration to dismiss.

Open the project

In a terminal already opened at the root of your disposable Git clone, run spore here. The first time, choose the code preset.

The terminal interface opens. The agent can read the project, edit its files and run its tests. It isn't editing a separate copy that later gets silently merged into your branch: you and the agent share the working directory.

A useful first task is one small behavior change with a precise acceptance condition. For example, in a project that has pagination:

Find the function that parses the page number from a query parameter. Implement this behavior: - A missing value returns page 1. - A string containing only decimal digits is accepted if its numeric value is a positive safe integer. - Empty strings, whitespace, signs, decimals, mixed text, zero, and values outside the safe-integer range are rejected using the project's existing error convention. Add tests for those cases. Run the relevant tests and report the commands and results. Keep the change small: no new dependencies or unrelated refactors. If the project has no pagination parser, tell me rather than inventing one. 

This is intentionally narrower than “improve validation.” You know what to inspect, and the agent has an explicit way to report that the task doesn't fit the repository.

The instruction isn't a security policy. It tells the model what work you want; access and execution limits belong to the runtime and configuration.

Inspect the changes before asking for more

After the agent answers, use this command inside Spore's terminal interface:

/diff 

This opens the changes since the current session began in Git's pager.

Read the actual implementation and tests. Does the parser accidentally accept a numeric prefix? Does it reject unsafe integers? Do the tests exercise the behavior, rather than just repeat the implementation's assumptions?

Run the project's tests yourself as well. An agent's report that tests passed is not a substitute for inspecting the command and its output.

What the snapshot does—and doesn't—mean

Spore makes a snapshot when the session opens, including untracked files, under its own Git ref. Your branch and staging area aren't moved by that snapshot.

Because the working directory is shared, /diff includes your edits too, not only the agent's. Ignored files are left alone by the snapshot/undo workflow.

Don't confuse a session snapshot with a commit, a backup of every file, or an audit that attributes each line to a particular author.

Leave, then return

Once the task has finished, close the terminal interface. Later, open a terminal in the same repository and run spore here again.

You return to the same spore and conversation. Its workspace still holds the programs and files it made; closing the screen hasn't turned that work into an expired chat session.

A follow-up could be:

Review the pagination change against the acceptance conditions from the previous task. Inspect the current files and rerun the relevant tests. Don't assume the repository is unchanged. Report any mismatch before editing. 

Persistence is not omniscience. You or another tool may have changed the project. The useful behavior is to inspect the current state and reuse relevant artifacts—not blindly trust a previous answer.

There is also a new session snapshot. After reopening, /diff compares against that new baseline. It doesn't automatically show the entire previous session's work. Use ordinary Git history and diffs for longer-term comparisons.

Undo is a deliberate operation

Inside the interface:

/undo 

Spore shows what restoring the session snapshot would change. Review that before proceeding.

Accepting the restore discards changes since this session opened, including your own changes in the snapshotted files. It isn't “undo only what the AI did.” Ignored files remain outside that mechanism.

This is why a disposable clone and a small task make a better first experiment than a busy working tree. Commit work you want to retain using your normal Git workflow.

Fewer built-in tools, not fewer possible tasks

Spore exposes seven built-in tools. It doesn't need a different model-facing tool for every file search, parser or service integration: ordinary programs provide those capabilities.

The related design choice is to keep useful procedures as programs. If a task repeats, the agent can write and test a helper, then run it again instead of reconstructing the procedure through another model response.

Large command outputs stay in files. The agent can search and read relevant pieces rather than automatically carrying the entire output into context.

These are design choices and guidance, not a guarantee that the model always chooses an efficient approach. Inspect the work and its records.

What stays outside the agent's control

The kernel enforces filesystem access boundaries. Provider and configured source credentials are held outside the agent, rather than handed to its programs. The runtime records activity and spend where the agent cannot rewrite them.

Time, spend and model-call limits apply per turn. Soft limits ask it to wrap up; hard limits stop further work according to the runtime's rules. An already-running model call can finish and add cost beyond the spend threshold. Aggregate budgeting across agents remains an operator responsibility.

Two boundaries matter when trying this in a project:

• Credentials held by a broker are different from secrets you leave in readable project files.
• Kernel confinement is different from network isolation. Additional egress policy belongs to the host.

The security explanation describes the trust boundary and its limitations.

What to look for in your first session

Don't judge only whether the final answer sounds plausible. Check:

• Was the requested change actually made?
• Were the specified cases tested?
• Did the agent stay within scope?
• Can you inspect its work and return to it later?
• Are you comfortable with the files and capabilities you granted it?

That's the small experiment: a familiar coding workflow, persistent artifacts and boundaries you can examine.

Install Spore · Source · Community

If you try it, I'd be interested in the task, your host setup and where the workflow gets in your way—not just whether the first answer looked good.

The next article will move from the terminal to an application: submitting work through Node or HTTP and reconnecting to the result.