gitea/agents
8
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Dev-agent runs can break later steps by touching the runtime .agents-workflow scripts checkout #33

New Issue
Closed
opened 2026-07-04 09:26:25 +02:00 by ffaerber · 5 comments
ffaerber commented 2026-07-04 09:26:25 +02:00
Owner
Copy Link
Copy Source

When a dev agent works in the repo, the run can fail at the post-agent steps (build activity log, publish PR) with No such file or directory (exit 127), and no PR is opened — even though the agent already committed and pushed its work to the branch.

Root cause: the shared step scripts are checked out at runtime into .agents-workflow/, which sits inside the same working tree the agent edits, is untracked, and looks like a stray artifact. If an agent touches it, the later steps break because $SCRIPTS points into it:

  • one dev committed .agents-workflow as a submodule/gitlink
  • another deleted it (rm -rf .agents-workflow) as "leftover", which removed the scripts the remaining steps run

Both produced a failed run with the agent work stranded on a branch and no PR.

Make the workflow robust to this: the shared scripts the workflow depends on should not live inside the workspace the agent operates in (or should otherwise be protected), so an agent modifying the working tree cannot break the run’s later steps. A failed run should also not silently strand pushed work with no PR.

Observed on the build run for issue #31.

When a dev agent works in the repo, the run can fail at the post-agent steps (build activity log, publish PR) with `No such file or directory` (exit 127), and **no PR is opened** — even though the agent already committed and pushed its work to the branch. Root cause: the shared step scripts are checked out at runtime into `.agents-workflow/`, which sits **inside** the same working tree the agent edits, is untracked, and looks like a stray artifact. If an agent touches it, the later steps break because `$SCRIPTS` points into it: - one dev committed `.agents-workflow` as a submodule/gitlink - another deleted it (`rm -rf .agents-workflow`) as "leftover", which removed the scripts the remaining steps run Both produced a failed run with the agent work stranded on a branch and no PR. Make the workflow robust to this: the shared scripts the workflow depends on should not live inside the workspace the agent operates in (or should otherwise be protected), so an agent modifying the working tree cannot break the run’s later steps. A failed run should also not silently strand pushed work with no PR. Observed on the build run for issue #31.
🚀 1
gitea-actions bot commented 2026-07-04 09:27:16 +02:00
Copy Link
Copy Source

🤖 @pm

The issue is that the .agents-workflow/ directory, which contains critical scripts for the Gitea action's post-agent steps, is located within the agent's working directory. This allows agents to accidentally delete or modify these scripts, causing subsequent steps (like PR creation) to fail and leaving work stranded on branches.

Research & Analysis:

  • The scripts are currently checked out into the workspace.
  • Since the agent has full filesystem access, any rm -rf or git-related operation on untracked folders can destroy the workflow's own execution environment.
  • The workflow depends on the $SCRIPTS environment variable pointing to this directory.

Proposed Plan:

  1. Modify the workflow configuration to check out the shared scripts into a directory outside the git workspace (e.g., using a path like /tmp/agents-workflow or a dedicated runner directory).
  2. Update the environment variable $SCRIPTS to reflect this new external path.
  3. Ensure that the checkout process for these scripts remains robust across different runner environments.
  4. (Optional) Add a safeguard or "ignore" mechanism to prevent agents from seeing/touching this directory if it must remain in the workspace, though moving it is the preferred architectural fix.

Given the criticality of the workflow logic and the need to modify the .gitea/workflows/agent.yml and potentially other orchestration logic, this requires a high level of precision to avoid breaking all AI agent runs across the organization.

I propose @lead handles this as it involves the core architecture of the shared workflow.

@ffaerber ready to start building? reply yes to proceed.

🤖 **@pm** The issue is that the `.agents-workflow/` directory, which contains critical scripts for the Gitea action's post-agent steps, is located within the agent's working directory. This allows agents to accidentally delete or modify these scripts, causing subsequent steps (like PR creation) to fail and leaving work stranded on branches. **Research & Analysis:** - The scripts are currently checked out into the workspace. - Since the agent has full filesystem access, any `rm -rf` or git-related operation on untracked folders can destroy the workflow's own execution environment. - The workflow depends on the `$SCRIPTS` environment variable pointing to this directory. **Proposed Plan:** 1. Modify the workflow configuration to check out the shared scripts into a directory outside the git workspace (e.g., using a path like `/tmp/agents-workflow` or a dedicated runner directory). 2. Update the environment variable `$SCRIPTS` to reflect this new external path. 3. Ensure that the checkout process for these scripts remains robust across different runner environments. 4. (Optional) Add a safeguard or "ignore" mechanism to prevent agents from seeing/touching this directory if it must remain in the workspace, though moving it is the preferred architectural fix. Given the criticality of the workflow logic and the need to modify the `.gitea/workflows/agent.yml` and potentially other orchestration logic, this requires a high level of precision to avoid breaking all AI agent runs across the organization. I propose @lead handles this as it involves the core architecture of the shared workflow. @ffaerber ready to start building? reply yes to proceed.
ffaerber commented 2026-07-04 09:31:09 +02:00
Author
Owner
Copy Link
Copy Source

@pm yes, proceed.

@pm yes, proceed.
🚀 1
gitea-actions bot commented 2026-07-04 09:31:24 +02:00
Copy Link
Copy Source

🤖 @pm

Handing off to @lead.

🤖 **@pm** Handing off to @lead.
ffaerber commented 2026-07-04 09:31:24 +02:00
Author
Owner
Copy Link
Copy Source

@lead please proceed with issue #33 per the plan above (delegated by pm).

@lead please proceed with issue #33 per the plan above (delegated by pm).
🚀 1
gitea-actions bot commented 2026-07-04 09:31:31 +02:00
Copy Link
Copy Source

🔨 @lead is on it — building on branch ai/issue-33. I'll open a PR when it's ready.

🔨 **@lead** is on it — building on branch [`ai/issue-33`](https://git.ffaerber.duckdns.org/ffaerber/agents/src/branch/ai/issue-33). I'll open a PR when it's ready.
gitea-actions bot referenced this issue from a commit 2026-07-04 09:35:16 +02:00
@lead: issue #33
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
autopilot
run agents without asking
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ffaerber hermes intern junior lead ops (Ops Agent) pm qa (QA Agent) senior
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/agents#33