Repository navigation
feat(agents): add global context information - #255
deviantintegral wants to merge 7 commits into
Conversation
2942b06 to
fe79352
Compare
m4olivei
left a comment
There was a problem hiding this comment.
Love this! I went back through about three weeks of Claude Code sessions in one Local VM and noted each time the agent needed to be told it was in Sandbar.
tmux: the agent often gave the stock Ctrl-b prefix. It only got Ctrl-a right when it happened to read ~/.tmux.conf. references/terminal.md should fix this.
Most of my other questions fell outside what the skill covers now:
- Host-side
sandcommands: thesand land … --reviewcommand for this checkout, upgrading sand, and changing memory. - Reaching guest services from the host: Postgres, and a
self-review-serveURL. - Review in the guest: the agent found
self-review-serveby listing/opt/sandbar.
Every time, the agent fetched several docs pages or cloned this repo to answer.
AI disclosure: I drafted this review with Claude Code, then reviewed and edited it myself.
Install shared environment guidance and agent-specific global instruction blocks for selected coding agents during clone provisioning. Preserve personal content and permissions, reject skill collisions, and keep task counts accurate for build progress.
Document global discovery paths, selected-agent deployment, preservation behavior, and guest sudo scope. Align the skill's tool reference with the standard base image and record successful validation.
An agent inside the guest cannot discover the name host-side `sand` commands take (the hostname can be customised away from it) or which connection profile type it runs on, which decides how a guest port is reached from the workstation. Emit both as sandbar_vm_name and sandbar_profile_type for the finalize and full phases; the identity-free base still receives neither. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hb2cwNrLqBrj8RLp4Qjic3
…nvironment skill Agents in a Sandbar VM kept answering host-side questions from general knowledge: which `sand` command to run on the workstation, how to open a guest port in the workstation's browser, where secrets come from, and how to show a diff for review. Add references for each, plus a templated this-vm.md naming the VM and its profile type, and widen the skill description and the global instruction block so agents load the skill for these topics. The reset reference leads with the fact that a reset deletes the guest unless a preserve flag is passed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hb2cwNrLqBrj8RLp4Qjic3
…kill The skill description only decides when the skill loads. Naming tmux keys alone missed questions about detaching or persistent sessions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hb2cwNrLqBrj8RLp4Qjic3
fe79352 to
c60f044
Compare
| A shell started before a global secret changed does not see the new value; | ||
| source `~/.config/sandbar/secrets.env` or start a new shell. Scoped `.env` | ||
| files load when a shell's prompt enters the directory. Claude Code also loads | ||
| them through its `SessionStart` and `CwdChanged` hooks, which run | ||
| `direnv export` for the session's working directory. |
There was a problem hiding this comment.
@deviantintegral I'm not totally sure this is the case / is intended / is necessary. I know there is direnv utility at play. I also know that for my one project, I didn't clone the repo per the onboarding of a new VM, so I ended up putting it into ~/projects/<project-folder>, so I'm not sure if that has something to do with why I don't seem to see secret additions / edits in existing sessions?
I know that I often see Claude run into trouble here, not seeing secrets changes, and so it has learned to source ~/.config/sandbar/secrets.env. Is that OK, or is that getting around intended behavior and/or hiding a real bug?
m4olivei
left a comment
There was a problem hiding this comment.
I'm comfortable with this, with the heavy caveat that I have very little context for the *.go code changes. Will leave this waiting on @deviantintegral 's 👍 .
deviantintegral
left a comment
There was a problem hiding this comment.
You asked about the golang code, it's good!
I have a few questions but do with them as you see fit. Thank you!
| | Review only part of the history | `sand land NAME PATH --review -- HEAD~2` (any `git diff` arguments) | | ||
| | Open a draft PR for a pushed branch | `sand land NAME PATH --pr` | | ||
| | Send a clipboard image into the guest | `sand paste-image NAME` | | ||
| | Change CPUs or memory | `sand reset NAME --cpus 8 --memory 16GiB` (see below) | |
There was a problem hiding this comment.
You don't have to reset to change cpu or memory - nothing stops you from editing the lima config or proxmox config.
The biggest gap right now is that those changes wouldn't get remembered if you did a reset after.
Perhaps we leave this as is, and improve things later to have a better workflow for this?
| @@ -0,0 +1,43 @@ | |||
| # Host-side `sand` commands | |||
There was a problem hiding this comment.
Do we need to consider that the user might be using the tui? I rarely use the CLI commands myself. I mostly want to make sure that a comfortable TUI user isn't pushed into the CLI side of things if it's not needed.
No description provided.