[xarmian]

Fixes BUG-4066 (phase 1; phase 2 is TASK-4072).

config.Load takes PAD_DATA_DIR verbatim, or PAD_DB_PATH's dirname, with no filepath.Abs. So every process resolves a relative value against its own cwd, and a CLI and a server started in different directories silently use different data: the database, the attachments, the key.

Phase 1 (lead ruling): resolution unchanged, plus a loud warning.

• One helper, envDataDir(), is the only reader of both variables; Load and userConfigPath use it. Every input resolves exactly as on main.
• A relative value warns once per process. The warning names the absolute data dir this process resolved (for PAD_DB_PATH, the directory of the file, not the file), says a CLI and a server in different directories will use different data, and says a future release refuses it. A literal ~ gets a hint.
• Where it goes:
  • a CLI prints it to stderr;
  • pad server start logs it through slog;
  • pad mcp serve prints it once on its own stderr. Its pad children (tool calls, the resource and bootstrap fetchers) run with an internal PAD_INTERNAL_NO_DATA_DIR_WARNING=1, so the warning never lands in an agent-facing error;
  • a server auto-started by the CLI does not inherit that variable, so it still logs the warning even when an MCP child started it;
  • silent for pad watch --stream --for-session (the plugin monitor) and for shell completion (__complete / __completeNoDesc).
• install-refresh.sh anchors the refresh marker and config_value the way section 2a anchors the log (${SERVER_CWD:-$PWD}). The marker is now written and cleaned up in one place; before, it leaked under the caller's cwd. The script warns once the server's cwd is captured, before the marker is written or anything is stopped, naming the server's path, with . and .. collapsed. It is one line, like the Go warning: when the caller's directory differs, that reading rides inside it.
• docs/deployment.md: both variables must be absolute; relative is deprecated and warns.

Tests

• The warning rule, including PAD_DB_PATH naming the data dir; Windows drive-relative and rooted paths are GOOS-guarded.
• The marker is present where the server looks while the restarted stub starts, and gone from both roots afterwards; the warning comes before the stop; both end to end.
• config_value at function level.
• Child-process tests: the monitor and completion stay silent (the completion cases run the real main()), the server logs through slog, and mcp serve warns once.
• Source scans: every pad exec in internal/mcp sets the child env, and internal/cli has exactly one server start spawn, which drops only the internal variable.

Harness guard. Every install-refresh exec in internal/buildtools passes requireSafeScriptEnv first. It refuses an environment where:

• the resolved port is missing (the script would fall back to 7777) or is numerically 7777 (07777 too). That check runs before any dial, so the guard never dials 7777;
• the config file's port is not a whole number (read the way the script reads it);
• PAD_HOST is set to anything but loopback;
• HOME or the data dir is the real user's, or is outside this test's temp dir;
• the port answers on a LAN address without this test's random stub token.

A source scan checks that each exec is guarded in its own function before it runs. The scan has its own self-test.

The guard exists because this unit's first draft of a test stopped the box's shared :7777 server twice. That draft never reached a commit.

Correction to the first commit's message: it says the script "warns before anything is read or stopped". Since r1 it warns once the server's cwd is captured, which comes before the marker and the stop. The text above is the accurate one.

https://claude.ai/code/session_01Hk4vxsaKDm3E1LvsoHtHeV