-
Notifications
You must be signed in to change notification settings - Fork 279
[Feature] gitagent run --workspace <dir> — separate agent directory from working directory #58
Description
Problem
When using gitagent run -d agents/my-agent -a claude, the Claude adapter sets cwd to the agent definition
directory. This means the agent operates on its own files (SOUL.md, skills/, etc.) rather than on a target
workspace.
This breaks the core gitagent design principle of separating agent definition from target workspace — the same
agent should be usable across different repos and tasks. Today, the only workaround for agents that operate
on external codebases is to export the system prompt manually and launch Claude Code yourself:
cd ~/code/my-target-repo
claude --append-system-prompt "$(gitagent export --format claude-code --dir ~/code/my-agents/autoresearch)"This bypasses gitagent run entirely, losing the runtime configuration from agent.yaml (model preferences,
max_turns, timeout, hooks, allowed tools, sub-agents).
Proposed Solution
Add a --workspace <dir> flag to gitagent run that sets the working directory for the spawned process
independently of the agent directory:
gitagent run -d agents/autoresearch --workspace ~/code/my-monorepo -a claude
The change in runners/claude.ts is small — the spawnSync call currently hardcodes cwd: agentDir:
const result = spawnSync(claudePath, args, {
stdio: 'inherit',
cwd: agentDir, // <-- always the agent directory
});Proposed:
const result = spawnSync(claudePath, args, {
stdio: 'inherit',
cwd: options.workspace ? resolve(options.workspace) : agentDir,
});With a corresponding option in commands/run.js:
.option('-w, --workspace <dir>', 'Working directory for the agent (default: agent directory)')This should apply to all adapters, not just Claude — any runner that spawns a process should respect
--workspace.
Additionally, agent.yaml could support a workspace field in the manifest schema so agents can declare their
workspace expectations:
workspace:
type: external # or "self" for agents that operate on their own directory
instructions: >
Run this agent in the root of a repo that contains
a program.md and an eval/ directory.This would serve as documentation and could be used by gitagent run to warn if --workspace is expected but not
provided.
Alternatives Considered
- gitagent export + manual claude invocation — works but loses all runtime config from agent.yaml (model,
max_turns, timeout, hooks, allowed tools, sub-agents). You end up reimplementing what gitagent run already
does. - --repo flag — clones the agent repo to a cache directory and runs there. Doesn't help because the cloned
directory becomes the cwd, not the caller's directory. - Symlinking the agent into the target repo — fragile, defeats the purpose of portable agent definitions.
Additional Context
Agents that need this include autonomous experiment runners, code reviewers, migration tools, and any agent
whose definition is maintained separately from the repos it operates on.