Reporter: mrizzi
Problem
When adopting a URL agent from a non-default branch (e.g. release-1.0), agent add resolves the branch to a commit SHA and stores only the SHA-pinned URL in AgentEntry.Source. The original branch name is discarded.
When agent update <name> is later called without an explicit SHA, runAgentUpdate falls back to forgeClient.GetRepo().DefaultBranch (agent.go ~403-408), silently switching the agent to track the repo's default branch instead of the originally adopted one.
The command help documents this behavior ("If no SHA is provided, the default branch HEAD is used"), but for adopters tracking a stable release branch, this is surprising and incorrect — there is no warning that the tracking branch has changed.
Reproduction
fullsend agent add myagent <agent-yaml-URL-on-release-1.0-branch>
- Agent is pinned to the SHA at the tip of
release-1.0 ✓
fullsend agent update myagent
- Agent is now pinned to the SHA at the tip of
main (or whatever the repo default branch is) ✗
Root cause
AgentEntry (config.go) has no Ref field — only Name, Source, Enabled, Runtime, Model, Effort
pinAgentURL (agent.go ~527-560) resolves the branch name to a SHA and overwrites info.Ref with the SHA before building the stored URL. The original branch name is lost.
runAgentUpdate (agent.go ~403-408) has no stored ref to use, so it calls GetBranchRef(ctx, owner, repo, repo.DefaultBranch)
Proposed fix
Persist the adopted ref so agent update re-resolves that branch and re-pins to a fresh SHA+hash (integrity preserved):
- Add a
Ref field to AgentEntry (persisted in YAML)
agent add / pinAgentURL: store Ref: release-1.0 on the entry before overwriting info.Ref with the resolved SHA
runAgentUpdate: if entry.Ref is set, call GetBranchRef(ctx, owner, repo, entry.Ref) instead of falling back to DefaultBranch
- Consider a
--branch / --ref flag on agent update for one-off overrides
Related issues
Reporter: mrizzi
Problem
When adopting a URL agent from a non-default branch (e.g.
release-1.0),agent addresolves the branch to a commit SHA and stores only the SHA-pinned URL inAgentEntry.Source. The original branch name is discarded.When
agent update <name>is later called without an explicit SHA,runAgentUpdatefalls back toforgeClient.GetRepo().DefaultBranch(agent.go ~403-408), silently switching the agent to track the repo's default branch instead of the originally adopted one.The command help documents this behavior ("If no SHA is provided, the default branch HEAD is used"), but for adopters tracking a stable release branch, this is surprising and incorrect — there is no warning that the tracking branch has changed.
Reproduction
fullsend agent add myagent <agent-yaml-URL-on-release-1.0-branch>release-1.0✓fullsend agent update myagentmain(or whatever the repo default branch is) ✗Root cause
AgentEntry(config.go) has noReffield — onlyName,Source,Enabled,Runtime,Model,EffortpinAgentURL(agent.go ~527-560) resolves the branch name to a SHA and overwritesinfo.Refwith the SHA before building the stored URL. The original branch name is lost.runAgentUpdate(agent.go ~403-408) has no stored ref to use, so it callsGetBranchRef(ctx, owner, repo, repo.DefaultBranch)Proposed fix
Persist the adopted ref so
agent updatere-resolves that branch and re-pins to a fresh SHA+hash (integrity preserved):Reffield toAgentEntry(persisted in YAML)agent add/pinAgentURL: storeRef: release-1.0on the entry before overwritinginfo.Refwith the resolved SHArunAgentUpdate: ifentry.Refis set, callGetBranchRef(ctx, owner, repo, entry.Ref)instead of falling back toDefaultBranch--branch/--refflag onagent updatefor one-off overridesRelated issues