fix: gate init "create a session" hint on active session - #781

_{Comment @coderabbitai help to get the list of available commands.}

This guards a state that can't currently occur — the stale hint doesn't reproduce

I tried to confirm the repro from #771 and it doesn't hold up. The claimed flow is:

1. minimal activate . — "verify $MINIMAL_SESSION_ID is set"
2. minimal init inside that session → stale activate/attach hints

Step 1's premise is false: $MINIMAL_SESSION_ID is never set in a minimald session shell, and the real minimal init can't run in-session anyway.

Evidence

• The var never enters a session process env. The session shell is spawned with BASELINE_VARS — literally just PS1 — plus the project's composition vars (crates/minimald/src/session_host.rs:796,982). MINIMAL_SESSION_ID is purely a channel-routing var: the host client puts it on the outgoing SSH channel (crates/minimal/src/client.rs:172, crates/minimal/src/lib.rs:1010 SendEnv), and minimald reads it back to select the session (connection.rs:390, exec.rs:779). The attach path (session.rs:695) uses the channel config only for PTY size + loadout and never injects its env vars into the spawned process — unlike stock OpenSSH, which places AcceptEnv vars into the shell. No test asserts the var is present in-session.
• The real minimal init isn't reachable in-session. /usr/bin/min inside the sandbox is the relay shim crates/minimald/src/env_min_helper.sh — verbs add / search / run / build / test / patched-pkg / check, no init — and it never invokes the minimal binary. minimald's exec path also refuses arbitrary commands (only min run <task>).

So in_session is false on every real path; the activate/attach hints print exactly as before, and the new branch is dead code.

Why it looked plausible

The chain was machine-generated and never verified against a running session: #771 was inbox-auto-routed with an LLM-written repro (it assumed SendEnv ⇒ the var lands in the shell, i.e. stock-sshd behavior, which minimald doesn't do); inbox-patch failed to produce a verified fix twice; and this PR's Verification ran only fmt/clippy/build, not the in-session repro.

Suggestion

One-line check inside a real session settles it:

minimal activate .        # then, in the session shell:
echo "MINIMAL_SESSION_ID=[$MINIMAL_SESSION_ID]"   # → empty

If it's empty (per the code above, it will be), I'd close #771 as not-reproducible. If we want init to be session-aware, the real prerequisite is a minimald change to export MINIMAL_SESSION_ID into the session shell env (and make init reachable in-session) — only then does this gate become live. The change itself is harmless (the host path is unchanged), so this is a "does it fix anything?" question, not a correctness objection.

Closing as invalid — this targets the wrong root cause.

The real repro (see the reporter's terminal): minimal activate on a project with no minimal.toml auto-scaffolds one and, as a sub-step, prints run_init_flow's "Next steps" block including minimal activate . # create a session — while activate is already running and proceeds to create the session. The trailing session UUID in the original report is the session activate just created, not evidence of a pre-existing/active session — which is what led the auto-generated issue and this PR to gate on MINIMAL_SESSION_ID.

That gate is dead code: MINIMAL_SESSION_ID is never set in this flow (it's a channel-routing var on the SSH channel, never in the CLI process env; the session shell env is BASELINE_VARS = just PS1), and run_init_flow only ever runs host-side as minimal init / activate's scaffold step — never in-session (the in-session min is a socat relay shim with no init verb). Details in the earlier comment.

The correct fix keys off the caller (activate auto-scaffold vs standalone init), not the env var — omit the activate/attach hints when run_init_flow is invoked from offer_mfile_scaffold (crates/minimal/src/lib.rs:867). I've re-diagnosed and rewritten the tracking issue #771 accordingly.