Repin octos to 056173e8 (reloaded tool rows show their tool's name) by ymote · Pull Request #298 · OctoSense-org/OctoSense

ymote · 2026-10-02T18:19:23Z

Moves OctoSense's one octos pin from ae230ce0 to 056173e8, the merge of octos-org/octos#2675. That PR fixes the root cause behind #281's partial fix.

The fix: reloaded tool rows name their tool. At ae230ce0, session/hydrate rows carried no tool name or call id. So after a reload, the system chat and the "Ask " panel showed every tool row as "⚙ tool · done". With octos#2675, a tool row carries tool_call_id and tool_name, and an assistant row carries its tool_calls. The fields reach every connection, including the shell's stdio link, which has no v2 envelopes. Both chat models already read tool_call_id and name/tool_name (system_chat/model.rs, app_chat/model.rs). The broker's merged_history passes rows through unchanged. No lookup change is needed. #281 (open) prefers a row's own name, so its turn-matching becomes a fallback for an older kernel. With this pin, a turn from before the shell's run is named too, which #281 alone could not do.

Confirmed against the real kernel. The two-lane scenario (host_tools::scenario_tests, step 3g) reloads both lanes at the new pin, with the scripted model that reuses call_1 for every call:

the panel's merged history has News's agent's news_share row with its call id, and Conversation::load_history shows it as news_share;
the system session's hydrate, through ChatModel::load_history, shows the delegation as peer_send_input.

What else the pin brings

octos PR	For OctoSense
#2672	`SessionOpened` gains `accepted_client_commands`, omitted when an open declares no `client_commands`. OctoSense declares none (AppCard passes `client_commands: None`) and builds no `SessionOpened`. No change.
#2671	Documents `session/open`'s `client_commands` (UPCR-2026-037) and rewords the gateway-only slash reply. No wire change.
#2669	octos docs only: an OctoSense integration walkthrough and octos's root `AGENTS.md`.
#2665	A skill that declares an env allowlist no longer receives undeclared secret-like `OCTOS_*` variables (such as `OCTOS_AUTH_TOKEN`) from the kernel's environment.
#2664	octos's own dev build profile. Nothing for OctoSense: a dependency's profile does not apply here, and the kernel artifact is a release build.
#2261	octos's credential store (`auth/keychain.rs`, which resolves the `keychain:` markers AI providers may write into `_main.json`) refuses symlinked or non-regular credential files and writes atomically; a failed save through octos keeps the old credentials. AI providers writes `_main.json` itself, so nothing changes on its side.

octos's dependencies are unchanged between the two revisions.

Files

The same set as the last octos repin (765dec2), minus the docs that no longer name a revision since #275:

Cargo.toml: the three octos revs and the pin's comment.
Cargo.lock: only the 17 octos source lines. A plain cargo update -p octos-* also reshuffled which already-locked windows-* version generator and iana-time-zone use. That churn is unrelated to octos and would collide with Repin the runtime to makepad 39a9de88 (OpenHarmony idle and input, GL GPU timing, terminal shortcuts) #289, so it is left out. cargo metadata --locked (setup.py --check --cargo) accepts the lock as is.
tools/test_kernel_artifact.py: REV. kernel-artifact.py --host --plan now names 056173e8.
docs/adr/0004-native-apps-hosting-and-peers.md and crates/toolbox/README.md: the pin.
crates/shell/src/host_tools/scenario_tests.rs: step 3g above.

Overlap

#289 (the makepad repin) also edits Cargo.toml and Cargo.lock, and merges first. This PR rebases after it and reruns setup.py --check --cargo. The octos lines do not overlap the makepad ones.

Verification

On the Linux build host (stable Rust, CARGO_BUILD_JOBS=12), at 31fec2bb. That is this commit before an amend that only updates the toolbox README's run record.

cargo test --locked -p octosense-kernel: 50 passed. That is 30 unit tests and 13 against the stand-in kernel; the 7 real-kernel tests return early without a binary and are run below.
cargo test --locked -p octosense-app-peers --features octos-core,ws: 104 passed (89 scripted; the 15 real-kernel tests returned early, run below).
cargo test --locked -p octosense-ai-host --features octos-core,llm: 38 passed, 1 ignored.
cargo test --locked -p octosense-toolbox: 83 passed (the README's run record now names this pin).
From phone/: cargo test --locked --features mobile-apps -p octosense-shell system_chat: 66 passed. ... app_chat: 9 passed.
The kernel at the new pin: python3 tools/kernel-artifact.py --host (7 min). It is cached on the host the way ci-local caches it (octos-kernel/Linux-x86_64-056173e8…/octos, under its per-revision lock).
Real kernel, with that binary:
- cargo test --locked -p octosense-kernel --test real_kernel -- --test-threads=1: 7 passed.
- cargo test --locked -p octosense-app-peers --features octos-core --test real_kernel: 15 passed.
- From phone/: cargo test --locked --features mobile-apps -p octosense-shell --lib host_tools::scenario_tests -- --test-threads=1 (the two-lane scenario, with step 3g): 5 passed. host_tools::real_kernel_tests (the shell's relay): 3 passed.
Negative control: the main scenario against the cached ae230ce0 kernel runs to the end, then fails at step 3g. Its merged history has two tool rows, and neither carries tool_name.
While the macOS jobs wait for a runner:
- phone.yml's main test step, run on Linux from phone/ with OCTOS_SHELL_TEST_KERNEL (cargo test --locked --features mobile-apps -p octosense-shell -p octosense-home -p octosense-app-policy -p octosense-app-hub -p octosense-appcard -p octosense-ai-host): 1128 passed, 1 failed. The failure was sandbox::tests::a_program_reached_through_a_link_outside_its_roots_starts, which hit "Text file busy": a probe was exec'd while a parallel test still held it open. Alone it passes 3 of 3 times, and all 23 sandbox:: tests pass.
- desktop.yml's cargo check --locked -p octosense and --features mobile-apps, on Linux: pass.

On the Mac: python3 tools/setup.py --update, then --check --cargo, and python3 tools/native_apps.py --check pass. python3 -m unittest discover -s tools -p 'test_*.py': 90 passed.

Not run (unverified): the desktop and home jobs on macOS (queued on GitHub), tools/ci-local.sh, the Android cross-build of the kernel artifact, and any device or instrument run.

🤖 Generated with Claude Code

The supervisor saw the kernel end (its stdout closing, or its exit status) and read the stderr tail at once, but stderr is copied into the tail by a task of its own. The line the kernel wrote just before it exited could still be in the pipe, so the reason lost it: CI's `a_kernel_that_dies_closes_its_connections_with_its_last_words` failed with "the kernel closed its output: fake kernel up", without the "asked to exit" the fake kernel wrote last. The tail is now read after the kernel is stopped and the stderr task has reached the end of the pipe (bounded at 2 s, for a process the kernel started that still holds the pipe). Failed reasons get the same complete tail. The test asks for the last words themselves, not just "exit". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… probes The glance tile tests register probe system apps (os.glancetile, os.glanceinput, os.glancequiet, os.glancesweep) in App Hub's system-app registry. That registry is process-wide, has no removal, and is the one `system_card_apps` lists, so a catalog test running after a glance test in the same process saw the probes as launcher rows: `bundled_apps_open_without_catalog_files_or_child_processes` failed its catalog comparison 7 of 10 times beside `glance_card::` on main, and `the_system_apps_ship_as_card_apps` compares the same list. Tests now register their system apps through `apps::test_system_apps::register`, which notes the id before it registers it, and the tests of the build's own catalog leave noted ids out. Production code is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`approvals::tests::the_relay_gets_decisions_made_before_it_was_installed` began with `init_memory()`, which replaces the shell's process-wide approvals with empty ones. Every consent a test running beside it had given was gone. `app_chat::tests::the_panel_opens_a_sharing_context_and_sends_person_turns_there` allows its app, then reads `agents::line()`, which reports a peer slug only while the app is allowed. Beside `approvals::` it failed 50 of 50 runs with `peer_slug: null`. The same test also installed its recording relay into the shared approvals, where it would take other tests' decisions. The relay seam (`approval_requested`, `set_relay`, `bus_requested`) is now methods on `Approvals`. The free functions call them on the shell's approvals, as before. The test builds `Approvals::memory()` and never touches the shared one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…the whole connect's `a_jail_only_app_reads_its_jail_and_is_refused_everything_else` failed on GitHub's macOS 14 runners with "the hub is reachable: " and nothing after it: the sandboxed `nc -z` exited 1 without a word, because nc prints why a connect failed only with `-v`. Its exit status says only that the connect did not complete. A sandbox refusal and a refusal past the sandbox (no listener on the port then, the network stack) look the same, though only the first is what this test is about. Closing the hub's listener before the probe reproduces the CI message exactly. The probe now runs `nc -v -n` and the test reads what nc says. The hub fails only on the sandbox's own refusal (EPERM from Seatbelt and seccomp, EACCES from Landlock), or when nc never reported a connect at all. A refusal past the sandbox is printed and passes. Any other port must now be refused by the sandbox itself, not just fail, which the old check could not tell apart. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

octos#2675 makes session/hydrate rows name their tool calls: a tool row carries tool_call_id and tool_name, an assistant row its tool_calls. The shell's system chat and "Ask <app>" panel already read tool_call_id and name/tool_name, and the broker's merged history passes rows through, so reloaded tool rows now show their tool's name instead of "tool". The two-lane scenario checks it against the real kernel: News's agent's news_share call in the panel's reloaded history, and the system chat's peer_send_input. The pin also brings #2261, #2664, #2665, #2669, #2671 and #2672. octos-core, octos-cli, octos-research and the kernel artifact move together; Cargo.lock changes only the 17 octos source lines. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ymote · 2026-10-02T22:04:26Z

Merged in a merge train; local CI (Mac with rom toolchain + --linux-host) passed on the train head 72e5d55, which contains this PR.

tools/ci-local.sh --only all --linux-host, started 2026-10-02T14:00:45: passed. Desktop, phone and apps passed on the Mac; apps services, kernel-security and linux-host / sandbox passed on the Linux build host. Its rom.yml steps were skipped on the Linux host, and the train doesn't trigger rom.yml.
tools/ci-local.sh --only all on the Mac with the rom toolchain (JDK 17, Android SDK, node 24), started 2026-10-02T14:51:21: 42/42 steps passed, none skipped.

The train was #291, #293, #297, #294, #298, #295, #296, #299, #300 and #292, on main f6678b5. After the last merge, main 301be0c has the tested head's tree.

ymote and others added 5 commits October 2, 2026 13:57

ymote force-pushed the chore/repin-octos-056173e8 branch from 313caa2 to db0e792 Compare October 2, 2026 20:59

ymote merged commit 84fdeab into main Oct 2, 2026
5 checks passed

This was referenced Oct 2, 2026

kernel: a dead kernel's close reason waits for its last stderr lines #291

Merged

fix(shell): the catalog tests read the build's apps, not other tests' probes #293

Merged

fix(shell): the relay seam's test keeps to approvals of its own #297

Merged

Navigation Menu

Repository navigation

Repin octos to 056173e8 (reloaded tool rows show their tool's name) - #298

Repin octos to 056173e8 (reloaded tool rows show their tool's name)#298
ymote merged 5 commits into
mainfrom
chore/repin-octos-056173e8

ymote commented Oct 2, 2026 •

edited

Loading

Uh oh!

Uh oh!

ymote commented Oct 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ymote commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What else the pin brings

Files

Overlap

Verification

Uh oh!

Uh oh!

ymote commented Oct 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

ymote commented Oct 2, 2026 •

edited

Loading