Run the engine natively (no proot in the hot path): structural fix for the untrusted_app transport corruption

[zo-sol]

STATUS UPDATE (2026-07-12): the T0 probe (comment below) killed this issue's core premise — the Ubuntu glibc rootfs cannot be launched through the bionic linker (non-PIE rejected; glibc rtld aborts on PHDR under bionic execve; even PIE glibc binaries segfault). The linker-chain modules below (T1/T2 as written) are dead on arrival. The revised plan of record is in this comment: Phase 1 — instrument and patch proot's transport under untrusted_app (timeboxed); Phase 2 — if unfixable, adopt a bionic (termux-ecosystem) userland for the engine. The in-app probe (NativeProbeActivity) stays as the standing on-device gate. Original text kept below for the record.

Goal

Eliminate the #112 bug class at the architecture level: run the four engine binaries (node, claude, codex, git) as native Android processes, with no ptrace layer between them and the kernel. The dulwich clone shim from #114 is an interim patch for one subcommand of one tool; this issue is the structural fix, and it must hold on Snapdragon and MediaTek devices and in the Play Store release build (targetSdk 35).

Context: #112 (root cause + verification threads), #114 (interim shim, merged as 509dee6), fix ladder: #112 (comment)

Why the current architecture breaks

Every engine syscall crosses proot's ptrace translation. Under the untrusted_app SELinux domain (targetSdk 35, required for Play), that translation corrupts multi-process piped/socket data — measured as truncated pack streams and TLS decode failures. Anything pipe-heavy (git today, npm/cargo tomorrow) is exposed.

flowchart TD
    WV["WebView UI"] --> SM["ServerManager"]
    SM --> GE{{"GuestExec seam"}}
    GE --> DPE["DirectProotExec"]
    DPE --> PROOT["proot (ptrace tracer)"]
    PROOT -->|"every syscall translated"| NODE["node server"]
    NODE --> CLAUDE["claude CLI"]
    NODE --> CODEX["codex CLI"]
    NODE --> GIT["git + git-remote-https + index-pack"]
    PROOT -. "CORRUPTS multi-process<br/>pipe/socket data under<br/>untrusted_app (#112)" .-> GIT

    style PROOT fill:#ffe9e6,stroke:#ef4444
    style GIT fill:#ffe9e6,stroke:#ef4444

Loading

Target architecture

Engine processes launch through the system linker into the glibc runtime that already ships inside our rootfs; the rootfs becomes a plain directory prefix (no path emulation). proot stays only as the convenience layer (user shell, apt) where the bug cannot break the product.

flowchart TD
    SM["ServerManager"] --> GE{{"GuestExec seam"}}
    GE -->|"per-binary strategy map<br/>node/claude/codex/git: native or proot"| NLE["NativeLinkerExec (new)"]
    GE -->|"fallback + shell/apt"| DPE["DirectProotExec (kept)"]

    NLE --> L64["/system/bin/linker64<br/>(system_linker_exec: may exec app-storage PIE)"]
    L64 --> LDSO["glibc ld.so from OUR rootfs<br/>(PIE; launches our non-PIE node/claude)"]
    LDSO --> NODE["node server (native)"]
    NODE --> CLAUDE["claude (native, HOME=rootfs/root)"]
    NODE --> GIT["git + helpers (native)<br/>multi-process is safe without ptrace"]
    NODE -.-> CODEX["codex (static musl)<br/>route decided by T0 probe;<br/>may stay under proot"]

    SHIM["libagentnet-redirect.so (new, ours)<br/>LD_PRELOAD interpose: /etc/resolv.conf,<br/>/etc/hosts, nsswitch -> rootfs copies"] -.-> NODE
    SHIM -.-> CLAUDE
    SHIM -.-> GIT

    ROOTFS[("rootfs = plain directory<br/>same files both strategies:<br/>HOME, .claude/, .gitconfig, TMPDIR")] --- NODE
    ROOTFS --- DPE

    style NLE fill:#e6f0ff,stroke:#3b82f6
    style SHIM fill:#e6f0ff,stroke:#3b82f6
    style L64 fill:#e6ffe9,stroke:#22c55e
    style LDSO fill:#e6ffe9,stroke:#22c55e

Loading

Elements to build

#	Element	What it is	Why it is needed
1	In-app probe screen (debug builds)	Hidden screen/broadcast that runs each chain step AS the app and reports errno + avc: denials	The failure is SELinux-domain-gated; adb run-as runs in runas_app and lies. All go/no-go data must come from untrusted_app
2	NativeLinkerExec : GuestExec	New strategy behind the existing seam; builds linker64 -> ld.so -> binary argv + env (HOME, TMPDIR, PATH, preload)	Engine launch without ptrace; DirectProotExec untouched as instant fallback
3	Per-binary strategy map	{node, claude, codex, git} -> native | proot from BuildConfig + probe cache, logged at boot	Rollout is per-binary, never all-or-nothing; codex (static musl) may legitimately stay proot'd
4	libagentnet-redirect.so	~100-line LD_PRELOAD interpose redirecting a fixed set of /etc/* opens into rootfs copies	Without path emulation, glibc DNS reads a nonexistent /etc/resolv.conf; this is the one filesystem illusion the engine still needs
5	Env/state bridge	HOME=<filesDir>/rootfs/root in both strategies; audit of absolute-path assumptions (.claude.json cwd entries, shebang spawns, /tmp)	Sessions, auth, and configs must survive switching strategies in either direction
6	Benchmark harness (device, in-app)	boot-to-200, spawn latency, git clone wall-clock, npm ci, TTFB, RSS — per strategy mix	#112 shipped through an unmeasured gap; no default flips without a filled table

Work items

• T0 probe: chain viability per binary (node/claude/codex/git) + DNS with/without redirect shim, on Seeker (MediaTek) AND a Snapdragon device. Kill criterion: if linker64 -> ld.so cannot launch or mmap under untrusted_app, stop here and redirect effort to a proot transport patch
• T1 NativeLinkerExec + strategy map (dark on main, default = proot)
• T2 redirect shim + contract test (DNS lookup + https clone, healthy and flaky link)
• T3 git native: clone/fetch/pull/push in-app, then DELETE the Fix #112: git clone in the proot guest under targetSdk-35 #114 dulwich shim (closes the fetch/pull gap noted in git clone always fails in proot (Android) guest — "remote did not send all necessary objects" (suspected Ubuntu 24.04 rseq regression) #112)
• T4 node server native (WebView still served, spawn matrix intact)
• T5 claude native; codex route decided by T0 data
• T6 benchmark table + device matrix -> flip defaults

Device and release gates (hard requirements)

• Verified on MediaTek (Seeker, MT6878, Android 16 — also carries the arm64 pointer-tagging constraint: the process_vm proot build must remain untouched for the convenience layer) and Snapdragon (any Android 13+), plus one Samsung One UI device before defaults flip
• Works in the Play release build (targetSdk 35, release signing, Play Protect): the probe suite runs on the release AAB build, not only debug
• Every stage behind a flag; a bad device report reverts to proot per binary without a new release

Non-goals / notes

• proot is not removed — demoted to the user-shell/apt layer
• No licensing delta: the glibc runtime already ships in our rootfs (LGPL, arms-length as today); the redirect shim is our code; nothing is copied from GPL apps (prior art for the linker chain exists in the wild at targetSdk 37, e.g. termux-play-store)
• AVF/pKVM was evaluated and closed as not currently viable (system-API-only + no device support on Seeker); tracked as a long-term watchlist in the git clone always fails in proot (Android) guest — "remote did not send all necessary objects" (suspected Ubuntu 24.04 rseq regression) #112 fix ladder

[mega123-art]

T0 probe result — native linker-exec is not viable with the glibc rootfs

Built the T0 in-app probe (branch feat/115-native-exec-probe, NativeProbe.kt / NativeProbeActivity) and ran it on-device from the untrusted_app domain. It runs each engine binary through both linker routes and reports which the device accepts:

• Route B — linker64 → glibc ld-linux → binary (bionic only bootstraps glibc's own loader)
• Route A — linker64 → the glibc binary directly (termux's route)

Device: SM-A356E (Exynos 1380, Android 16), targetSdk 35 release policy.

Result: both routes fail, and preflight is all green

Preflight confirmed /system/bin/linker64, ld-linux-aarch64.so.1, and every lib dir exist — so these are real failures, not mis-pathed:

Binary	Route A (direct)	Route B (glibc ld.so)
node (ET_EXEC)	unexpected e_type: 2	SIGABRT: Could not find a PHDR
getent (PIE)	SIGSEGV (139)	SIGABRT: PHDR
claude / codex / git	ride node	same abort

Three independent conclusions:

1. Route A can't load our binaries. node is ET_EXEC (non-PIE); bionic's linker only loads PIE → unexpected e_type: 2 (the same rejection the README already documents).
2. Route B can't init glibc. bionic does load glibc ld-linux (it's ET_DYN), but glibc rtld then aborts — under bionic's execve the auxv doesn't hand glibc the PHDR it needs to self-initialize.
3. PIE won't save us. getent is PIE (it cleared route A's e_type gate) and still segfaulted. So even rebuilding every binary PIE does not help — glibc's libc does not survive Android's bionic linker (TLS / symbol init).

Why termux works and we can't borrow it

Termux's userland is PIE built against termux's own bionic-compatible libc — not glibc. The /system/bin/linker64 trick runs those binaries. The premise in this issue — "reuse the Ubuntu glibc already inside our rootfs" via the system linker — is technically impossible: glibc + bionic linker are incompatible at the loader/libc level, independent of the W^X / exec-from-storage concern. The licensing caution in the issue is real but it's not the blocker; this is.

The failure mode (bionic rejects ET_EXEC; bionic-loaded glibc rtld can't find PHDR) is a property of bionic + glibc, not device-specific, so Snapdragon/MediaTek are expected to behave the same. (Can confirm on those if we want a second data point.)

Where this leaves us

proot stays. T1–T6 as specified (NativeLinkerExec over the glibc rootfs) are dead on arrival. Real paths to kill the proot pipe/socket corruption:

• A. Extend the in-proot per-binary shim. The git dulwich shim (Fix #112: git clone in the proot guest under targetSdk-35 #114) already fixes the one pipe-heavy tool inside proot. Extend that pattern to any other offender. Lowest risk, matches what ships.
• B. Go termux-style for real. Replace the glibc rootfs with a bionic/musl PIE userland (native node, native git). This is the only way native actually works — but it's a full userland re-architecture, not a linker flag, and claude/codex still need a working node.
• C. Static-musl node only. Ship one statically-linked musl PIE node for the hot path (the server), run it native, keep proot just for git/pkg management. Middle ground: native where it matters, no full rebuild.

The probe stays in-tree as the on-device gate for whichever path we pick (re-run on any candidate binary: adb shell am start -n com.iqlabs.agentnet/.NativeProbeActivity, report → logcat AgentNet/Probe).

[zo-sol]

Excellent probe work — accepting the result fully. The PIE control case (getent clearing route A's gate and still segfaulting) settles it: bionic's linker cannot bootstrap the glibc world, so this issue's premise ("reuse the Ubuntu glibc rootfs via the system linker") is dead. Termux works because its userland is built against bionic, not because of the linker trick alone. My research missed that layer; good catch.

That said, I want to push back on option C (static-musl node only) as the plan of record, against our own measurements:

1. "claude/codex ride the native node for free" doesn't hold. claude is a glibc native vendor binary, not JS-on-node (ELF-parsed from the shipped rootfs: ET_EXEC, dynamic glibc). With node native, claude — and every Bash tool execution the agent makes — still runs under proot.
2. The corruption is not node's IPC. On the A35 the server was fine and git's own helper pipeline corrupted; the failure is a property of any multi-process piped I/O under the tracer.
3. So option C protects our app's plumbing, but the product promise is "a Linux box a coder can use" — and the unpredictable part (npm install, cargo, pip, arbitrary tools in agent shells) all stays on the corrupted transport. That's the whack-a-mole path: we'd keep shipping per-tool shims as users find new breakage. It also adds its own compat surface (musl node native addons, resolver differences).

Given glibc-native is closed, the remaining foundation-level fixes are:

Phase 1 — patch proot's transport (timeboxed ~2 weeks, do this first). It's now the only path that fixes ALL tools while keeping the real Ubuntu userland users can apt install into. We already build a custom proot (the Seeker process_vm build), so we own the pipeline. First hypothesis to instrument: process_vm_readv/writev partial-transfer/failure handling under untrusted_app — consistent with the corruption being domain-gated (runas_app clean) and load/fragmentation-sensitive. Vehicle: an instrumented libproot.so in a branch APK, gated by the probe activity you built (it's the right harness for this too). Deliverable either a patch or a precise "unfixable because X".

Phase 2 — if Phase 1 fails: the real option B, but by adoption, not rebuild. Replace the engine userland with termux's existing bionic package ecosystem (node and git already exist as bionic PIE packages; codex is static musl already; claude needs re-verification via its JS/npm path on that node — known to run on termux in the wild). Side benefit: ~1GB rootfs → ~150MB prefix. Keep the Ubuntu proot as an opt-in legacy layer.

Optional 2-day spike, in parallel: proot's own userspace ELF loader (libloader.so) loads and jumps into guest binaries without any kernel execve — that mechanism minus the ptrace tracer is a theoretical third route that keeps glibc AND removes the corrupting layer. Unproven (stack/auxv setup, no path translation), but it's the only idea on the table that preserves the current rootfs natively, so one probe run is cheap relative to what it would save.

Suggested order: Phase 1 instrumentation now; option C only as a later perf optimization if it still matters after the transport is fixed; the probe stays as the standing on-device gate (agreed — and please keep runs on Snapdragon/MediaTek as you offered, so the bionic/glibc conclusion gets its second data point).

Context for the requirement bar (from the team): the goal is an OS-like foundation that behaves predictably under user behaviors we cannot enumerate — coders will run arbitrary toolchains. Fix-the-basement beats error-by-error patching even at higher cost. That bar is what rules out C-as-the-fix and points at Phase 1/2.

[zo-sol]

Reproducible assets committed at debug/issue-115/ (commit 7168157) — probe scripts, shim sources (zig cross-compile), and a README with staging steps for a fresh device. This makes the hunt continuable by anyone, not just on this phone.

Root-cause hunt handoff — proot loses git object files under untrusted_app

Live debugging narrowed #112/#115 from "network corruption" down to git's loose-object write path. Complete handoff: what's proven (each by an experiment or a source line), the exact next probe (staged on device + in the repo), and the method to continue.

What is PROVEN (eliminated, each with its experiment)

Failure: in-app git clone -> fatal: remote did not send all necessary objects / bad object.

1. rseq is not it. GLIBC_TUNABLES=glibc.pthread.rseq=0 is live in the app process (verified in /proc/<node>/environ), clone still fails. Keep it as a cheap guard; not the fix.
2. Domain matters — run-as lies. App-spawned processes run in SELinux u:r:untrusted_app; adb shell run-as runs in u:r:runas_app. The bug reproduces ONLY in untrusted_app. A 56-clone run-as harness all passed. Every experiment must run as a true child of the app (in-app agent Bash), never run-as.
3. Socket receive is not it. recv() (the symbol curl calls) got the full ~10 MB; rerouting it through the untrapped read syscall (LD_PRELOAD) still failed. Pipe write was complete (short=0 err=0).
4. Network is fully exonerated. git clone --no-local of a local seed repo (zero network) fails identically.
5. --link2symlink is not it. ln gives links=2 (a real hardlink, not a faked symlink).
6. Plain rename/mv works — including rename into a 2-char subdir like git's objects/xx/.

The finding

git hash-object -w (write ONE loose object) reports success, but the object file never lands on disk: find .git/objects -type f = 0. Writing 50 objects: hash-object reports 50/50 OK, 0 survive. Ordinary writes/renames are fine; only git's object write loses data. (probe5, probe6, on-device.)

The ACTUAL git code path (read the source, not a guess)

An earlier round guessed O_TMPFILE. git 2.43 object-file.c disproves it — read it before instrumenting:

• create_tmpfile() (object-file.c:1911) -> git_mkstemp_mode(tmp, 0444) -> open(pattern, O_CREAT|O_EXCL|O_RDWR, 0444) (wrapper.c:489). A named temp file objects/xx/tmp_obj_XXXXXX, NOT O_TMPFILE.
• close_loose_object() (object-file.c:1877) -> fsync then close.
• finalize_object_file() (object-file.c:1819): link(tmpfile, filename) first; on failure, rename fallback; then unlink(tmpfile). If link returns 0 it treats the object as written.

So the syscalls that decide whether the object survives are exactly fsync / link / rename. Since hash-object reports success (finalize returned 0) yet 0 files exist, the prime suspect is precise: proot's link() returns 0 (false success) while the target never appears — or fsync silently drops the data. Note ln in probe5 worked, so it's git's specific sequence (0444 mkstemp temp -> fsync -> link within objects/xx/) that must be caught, not link in isolation.

NEXT STEP — staged on device (and in the repo), run this one probe

probe9 hooks the real finalize syscalls (link, rename, fsync) via /root/libobjtrace.so and, after each link/rename, checks whether the target actually exists:

# paste into the in-app agent chat:
run sh /root/probe9.sh and save the full output to /root/probe9_result.txt

Read it: adb shell "run-as com.iqlabs.agentnet cat files/rootfs/root/probe9_result.txt"

Decision:

• link ret=0 ... target_exists_after=0 -> caught: proot link is a false success. Root cause. Fix = proot linkat path-translation, or preload a shim that makes git use rename (which works: probe6).
• link ret<0 then rename ret=0 target_exists_after=0 -> rename is the false success instead.
• fsync ret<0 or data missing despite ret=0 -> fsync path drops the write; test git -c core.fsync=none -c core.fsyncObjectFiles=false clone.
• All three return 0 AND target exists, yet the object is unreadable later -> the temp file's content is corrupt; next probe captures the temp file and compares its hash.

Fix, once the guilty syscall is confirmed

• Interim (app-level, no proot rebuild): LD_PRELOAD shim in the guest env (ServerManager.buildGuestEnv or /etc/profile.d) that routes the failing operation to the working one (e.g. force rename instead of link). Broad — covers all tools, not just git.
• Basement (proot patch): fix the offending translation in our custom proot build (we own it from the Seeker process_vm fix). GPLv2 — publish the patch only.
• Note: the merged dulwich shim (Fix #112: git clone in the proot guest under targetSdk-35 #114) sidesteps this for clone only because dulwich writes objects with plain create+rename, not git's link path — which retroactively points at the finalize path, not the network.

How to debug (reuse this loop for every step)

Hard constraint: run inside the app's proot (untrusted_app), not run-as.

1. Stage a probe into the guest (run-as is fine for writing files — same uid):
   base64 -i probeN.sh | adb shell "run-as com.iqlabs.agentnet sh -c 'base64 -d > files/rootfs/root/probeN.sh'"
2. Trigger from the app domain by pasting ONE line into the in-app chat (the agent runs it via Bash = a true app child), saving to a file so the desktop can read raw output:
   run sh /root/probeN.sh and save the full output to /root/probeN_result.txt
   then adb shell "run-as com.iqlabs.agentnet cat files/rootfs/root/probeN_result.txt"
3. Native probes (LD_PRELOAD shims): cross-compile for the guest's aarch64 glibc with zig, no NDK:
   zig cc -target aarch64-linux-gnu -shared -fPIC -O2 -o libX.so libX.c
adb push libX.so /data/local/tmp/ && adb shell "run-as com.iqlabs.agentnet sh -c 'cp /data/local/tmp/libX.so files/rootfs/root/'"
   In the probe: LD_PRELOAD=/root/libX.so git .... proot's own libproot.so is at codePath/lib/arm64/ (dumpsys package com.iqlabs.agentnet | grep codePath).
   Fast reproducer: git clone https://github.com/expressjs/express.git in-app, or the local-seed clone for a no-network repro.

Method / principles (read before touching anything)

1. Read the relevant source FIRST, then decide what to instrument. This hunt burned a round on an O_TMPFILE guess that object-file.c refutes on sight (git uses mkstemp+link, not O_TMPFILE). Never hypothesize about a syscall before reading the code that issues it — open the source, find the exact function, then instrument that.
2. Never guess — prove. Every line above is backed by an on-device experiment or a source citation. If you can't point to one, it isn't a finding yet; it's a hypothesis to test, and it must be labelled as such.
3. One variable per probe. Change one thing, measure, record to a file, read it back. Keep the probes and results as the paper trail (that's what these probeN scripts are).
4. It's Linux — dig to the syscall. The bug is a concrete syscall misbehaving under proot. Keep narrowing (network -> object write -> the exact link/rename/fsync) until one syscall is caught red-handed with a return value that contradicts the filesystem. Stop only when you can name it.

Cleanup owed

On device /root/: probe{2..9}.sh, librecvshim.so, libtraceshim.so, librecv2.so, libnotmpfile.so, libobjtrace.so, trace-/objtrace.log, probe_result.txt. Desktop /tmp/recvshim/, /tmp/git-src, /tmp/proot-src. Remove once the fix lands. ADBKeyboard was installed for IME automation (crashed, unused): adb uninstall com.android.adbkeyboard. (On a fresh machine none of this applies — assets are in the repo.)

[zo-sol]

Start here — entry point for whoever picks this up

Everything you need is in the repo and this issue. You do not need this session's phone or laptop:

1. Read the handoff comment above — proven eliminations (rseq, socket receive, network, l2s, rename all ruled out), the exact git 2.43 code path (mkstemp -> fsync -> link -> unlink), and the next step.
2. Get the assets: debug/issue-115/ on main — all probe scripts, the LD_PRELOAD shim sources (zig cross-compile, no NDK), and a README with per-device staging steps.

You're on a different machine — so ignore this session's leftovers entirely: anything staged on the session phone's guest (/root/probe*.sh, /root/lib*.so), the laptop's /tmp/*, and any clipboard. None of it is needed and none of it transfers. The repo is the single source of truth — clone it, follow debug/issue-115/README.md to stage the probes + shims onto your own reproduce device, and run probe9.

Reproduce device = any Android AgentNet build where in-app git clone fails (untrusted_app / targetSdk-35). Hard rule from the handoff: run probes as a true child of the app (paste into the in-app agent chat), never adb run-as — different SELinux domain, won't reproduce.

Current best lead to confirm with probe9: proot's link() returning 0 (false success) while the object file never appears. Prove it, name the syscall, then fix (interim LD_PRELOAD shim, or the basement proot patch).

[mega123-art]

CONFIRMED root cause + fix, verified end-to-end on device

Followed the handoff. probe9 caught the syscall, a fix probe proved the cure, and the fix is verified through the real shipping path. All headless on an untrusted_app device (SM-A356E, Exynos 1380, Android 16).

probe9 — the syscall, caught red-handed

=== writing one loose object with link/rename/fsync instrumented ===
f06b470cb69ee8f19554b078710cf834cfb3482e
hash-object exit=0
=== objtrace.log ===
link ret=0 errno=0 target_exists_after=0  .git/objects/f0/tmp_obj_mvrgkg -> .git/objects/f0/6b470cb69ee8f19554b078710cf834cfb3482e
=== objects actually on disk ===
count=0

proot's link() returns 0 (success) while the target never appears. git trusts the 0, finalize_object_file reports the object written (hash-object exit=0), and nothing lands. Exactly the hypothesis in the handoff — the current best lead is now proven, not guessed.

The fix — core.createObject=rename (one line, no shim, no proot rebuild)

git 2.43 finalize_object_file (verified against v2.43.0): with core.createObject=rename (OBJECT_CREATION_USES_RENAMES) git skips link() entirely and uses rename(), which proot handles correctly (matches probe6). probe10 proves it:

link mode  (git default):        ok=50/50 reported,  survivors_on_disk=0    ← bug reproduced
rename mode (core.createObject):  ok=50/50 reported,  survivors_on_disk=50   ← fixed
real express.git clone WITH fix:  clone exit=0, done.

Verified through the SHIPPING path (system gitconfig, plain clone)

Wrote /etc/gitconfig [core] createObject = rename (what the installer now does) and ran an unmodified git clone — no per-command flag:

git config --show-origin core.createObject   ->  file:/etc/gitconfig   rename
git clone https://github.com/expressjs/express.git   ->  clone exit=0, done.
HEAD=ae6dd376 (commit)   in-pack: 53322   packs: 1   checkout: OK   worktree files: 213   fsck errors: 0

Full repo, clean checkout, zero fsck errors. The remote did not send all necessary objects failure signature is gone.

Shipped

• fix/115-git-object-rename — Installer.configureGuest writes the system /etc/gitconfig, so every git (the node server's and the user's interactive shell) gets it, not just clone. Also carries probes/probe10.sh (the fix test) and shims/liblinkfix.c (a broader LD_PRELOAD option — EXDEV on object-path link → caller's rename fallback — for any non-git tool that hits the same false-success).

This supersedes the clone-only dulwich shim (#114): real git, every command, one config line. #115 T3 (remove the dulwich shim) can proceed once this lands.

Headless reproduction (removes the in-app-chat staging friction)

The hard rule was "must run as a true app child (untrusted_app), never run-as." Added a guest-script mode to NativeProbeActivity (branch feat/115-native-exec-probe): it runs any guest script through proot from the app process, so the git under it inherits untrusted_app — same domain + proot path as the in-app chat, but drivable over pure adb with no agent auth:

adb shell am start -n com.iqlabs.agentnet/.NativeProbeActivity -e guestScript /root/probe10.sh
adb logcat -d AgentNet/Probe:I '*:S'

Every result above was produced this way.

Still open (the basement, per the revised plan)

core.createObject=rename fixes git — the only proven-affected tool today. The all-tools basement fix remains patching proot's linkat translation so link() stops lying for every tool (npm/cargo/…), in our own proot build (we own it from the Seeker process_vm fix; GPLv2 → publish the patch). That stays the long-term structural fix; the config change is the immediate, verified one to ship now.

[mega123-art]

Update: found the real root cause — it's --link2symlink, and the fix is to remove it

The core.createObject=rename gitconfig (first commits) fixes git, but git isn't the only victim. Dug to the actual root cause; it's one flag, and removing it fixes every tool at once.

Root cause (proven on-device, SM-A356E, untrusted_app)

In the untrusted_app domain the kernel denies hardlinks: ln a b → Permission denied, links=1. We launch proot with --link2symlink, whose extension catches that denial and fakes success — it pokes the syscall result to 0 and swaps in a symlink-refcount scheme (moving the file into PROOT_L2S_DIR, replacing the target with a symlink). That fake defeats callers' own error handling:

• git finalize_object_file falls back to rename only when link fails — never when it returns a lying 0.
• pnpm's store-linker falls back to copy only when the hardlink fails — never when it lies.

So both get a 0, skip their fallback, and the symlink dangles → silent git object loss and broken pnpm installs. This is exactly probe9's link ret=0 target_exists_after=0.

The fix: drop --link2symlink

Then linkat fails honestly with EACCES and every tool with a fallback recovers itself. Verified on-device with l2s off:

ln a b:                     Permission denied  (honest — no more fake success)
git (forced link mode):     50/50 loose objects survive   (rename fallback)
pnpm (default hardlink):    589/589 files, require OK      (copy fallback)
node server boot:           server ready (HTTP 200)        (no regression)

One flag removed fixes git + pnpm + any link()-using tool — no proot rebuild, no per-tool config. This is the "fix the basement" answer: the defect was proot faking a syscall, and we stop it faking.

What this PR now contains

1. DirectProotExec: remove --link2symlink — the root-cause fix, all tools.
2. Installer: core.createObject=rename system gitconfig — kept as belt-and-suspenders for git (skips the doomed link attempt entirely), and written on every launch so existing installs get it without a rootfs re-extract.

Supersedes the clone-only dulwich shim (#114) — real git, all commands, plus pnpm and the rest. #115 T3 (remove the dulwich shim) can proceed.

Note on the earlier "l2s isn't it" elimination

The handoff eliminated --link2symlink because ln showed links=2 (a real hardlink). That test was in runas_app, where hardlinks are allowed — so l2s passed the real link through untouched and looked innocent. The bug only appears in untrusted_app, where the real link is denied and l2s's fake-success path activates. Same reason the whole bug is domain-specific.