Skill activation: `/workspace/.skills/<name>` missing scripts/data subdirs on docker backend (nested bind mount)

[huanghuoguoguo]

Issue: Activated skill's subdirectories (scripts/, data/) missing under /workspace/.skills/<name> (docker backend)

Status: Open — NOT caused by the skill all-tool-model branch (feat/agent-runner-plugin). Confirmed via git: the entire mount/register/package chain is byte-identical to origin/master.

Symptom

After an agent creates → registers → activates a multi-file skill, running its script from the activated mount path fails:

exec workdir=/workspace/.skills/lb-e2e-skill  cmd="python3 scripts/use.py"
-> exit_code=2  stderr="python3: can't open file '/workspace/.skills/lb-e2e-skill/scripts/use.py': No such file or directory"

Inside the running sandbox container:

• /workspace/lb-e2e-skill (where the agent built it) → has SKILL.md + scripts/use.py
• /workspace/.skills/lb-e2e-skill (the activate mount point) → empty

So activate succeeds (skill registered, manager.py: Loaded 1 skills, mount point created), but the activated path does not expose the skill's scripts//data/ subdirectories — only the top-level SKILL.md is recognized.

Repro

1. local docker backend, host shares filesystem with box (shares_filesystem_with_box=True).
2. Agent: exec to create /workspace/<skill> with SKILL.md + scripts/use.py.
3. register_skill path=/workspace/<skill> → box_service.create_skill → Box runtime skill store.
4. activate skill_name=<skill>.
5. exec workdir=/workspace/.skills/<skill> cmd="python3 scripts/use.py" → No such file.

Diagnosis (where it breaks)

• register_skill (skill_authoring.py) resolves the sandbox dir to a host path and calls skill_service.create_skill({package_root: host_path}) → box_service.create_skill → self.client.create_skill (Box runtime, SDK).
• package_root consumed at activation comes from Box runtime list_skills() (manager.py: "Loaded N skills from Box runtime"), not the agent's raw workspace dir.
• build_skill_extra_mounts (box/service.py:261) bind-mounts that package_root to /workspace/.skills/<name> — while /workspace itself is already bind-mounted to data/box/default. This nested bind mount (mounting a workspace subdir back into another path inside the same workspace), under docker + shared filesystem, ends up exposing an empty dir.

Two non-exclusive root causes to confirm:

1. Box runtime skill store packaging may only persist SKILL.md/metadata, not the scripts//data/ subtree, so package_root points at an incomplete copy.
2. Docker nested bind mount of a path inside an already-bind-mounted /workspace is masked/empty.

Code ownership (git evidence)

The whole chain is unchanged by feat/agent-runner-plugin:

layer	file	feat vs master
mount helpers	skill.py (get_visible_skills / package_root / parse_skill_mount / resolve_virtual)	0 changes
host skill service	box/service.py (build_skill_extra_mounts, create_skill)	unchanged (only box-session-id-template lookup source changed elsewhere)
SDK mount exec	langbot-plugin-sdk/box/backend.py (docker run + -v extra_mounts)	0 changes
SDK skill store	SDK box/ (Box runtime create_skill / list_skills)	0 changes

build_skill_extra_mounts (the nested-mount logic) was introduced in 96b04184 "Feat/sandbox (#2072)" (2026-06-03); later hardened by 8e558ad3 (only added a package_root existence guard). The all-tool-model branch only exposed this path end-to-end for the first time (agent can now reach activate→exec-on-mount), it did not change the mounting code.

Unconfirmed

• Whether skill activation e2e was ever actually run-and-passed on the docker backend before (QA case sandbox-skill-authoring-e2e.yaml exists, but no pass record found in master's STATUS). The flow may have only been exercised on nsjail/E2B, or this docker+shared-fs nested-mount case may have always failed.

Suggested fix directions

• When host shares filesystem with box, avoid nested bind-mounting package_root into /workspace/.skills/<name>; instead create a symlink inside the workspace (/workspace/.skills/<name> → the real skill dir), sidestepping docker's masking of nested mounts.
• And/or verify Box runtime's skill store persists the full package (incl. scripts/, data/), not just SKILL.md.

Reproduction env

• backend=docker, image rockchin/langbot-sandbox:latest, host_path=data/box/default, mount_path=/workspace, read_only_rootfs=true.
• Pipeline 3e645b04-... (Agent QA Local Agent Debug Chat), model claude-opus-4-8.

[huanghuoguoguo]

Update: reproduced on clean master, root cause corrected, fix implemented & verified

1. Reproduced on master (NOT introduced by feat/agent-runner-plugin)

Ran the canonical sandbox-skill-authoring flow on a clean master checkout using the built-in local-agent runner (@runner.runner_class('local-agent'), src/langbot/pkg/provider/runners/localagent.py) — no plugin runner involved. The agent executed exec → register_skill → activate → exec(workdir=/workspace/.skills/<skill>), and the last step failed with the exact reported symptom:

exit_code=2  stderr="python3: can't open file '/workspace/.skills/<skill>/scripts/use.py': No such file or directory"

docker inspect on the sandbox container showed only data/box/default -> /workspace — the skill's -v package_root:/workspace/.skills/<skill> mount was never applied. So this is a master-native bug, confirmed end-to-end.

2. Root cause — corrected

The "docker nested bind mount is masked/empty" hypothesis (root cause #2 in the issue) is wrong. An isolated docker test shows a nested bind mount (mounting a /workspace subdir to /workspace/.skills/<name>) applied at container creation works perfectly — the content is visible. Docker does not mask nested mounts.

The real cause is container reuse + mount timing:

1. The sandbox container is created on the first exec (when the agent writes the skill files) — before the skill is registered — so build_skill_extra_mounts (pkg/box/service.py) returns no mount for it.
2. After register_skill + activate, later exec calls recompute extra_mounts (now including the skill), but the Box runtime reuses the existing container by session_id. extra_mounts is not part of _assert_session_compatible's _COMPAT_FIELDS (langbot-plugin-sdk/src/langbot_plugin/box/runtime.py), so the reused container is kept as-is.
3. A bind mount cannot be added to an already-running container, so the freshly-computed skill mount is silently dropped, and /workspace/.skills/<skill> is just an empty placeholder directory on the shared /workspace bind mount.

This is deterministic, not a flaky/topology issue.

3. Fix (langbot-plugin-sdk, box/runtime.py)

Make the Box runtime recreate the container when the requested mount set changes:

• _RuntimeSession now records the extra_mounts_key (signature of effective bind mounts) the container was created with.
• New helper _compute_extra_mounts_key(spec) mirrors the backend's mount filtering (skips mode == "none").
• In _get_or_create_session, when an existing live session's extra_mounts_key differs from the new spec's, the session is dropped and recreated (instead of reused).

Properties:

• Idempotent — only recreates when the mount set actually changes; once mounts are stable there is zero extra cost.
• Recreating a container is unavoidable anyway, since docker cannot add a bind mount to a running container.
• No data loss — /workspace and the skill store are persistent host bind mounts; with read_only_rootfs=true the container rootfs is stateless.

4. Verified on master

Same flow, after the fix:

• Agent final response: E2E_OK:<skill>.
• The activation exec (workdir=/workspace/.skills/<skill>) returns exit_code=0 with SANDBOX_COMPLEX_SKILL_OK ... and SANDBOX_ACTIVATED_WRITEBACK_OK.
• Container mount table now includes .../data/box/skills/<skill> -> /workspace/.skills/<skill>.
• The activated path contains SKILL.md, scripts/, data/, and activated_writeback.txt.

The fix belongs in langbot-plugin-sdk; LangBot's build_skill_extra_mounts already does the right thing (recomputes mounts every exec) — the gap was purely the Box runtime reusing a container without honoring mount changes.