Allow overriding trace dir and default workspace via env vars (decouple from cwd)

[scrambled2]

Summary

@farfield/server derives both its trace dir and the default workspace for new Codex threads from process.cwd():

https://github.com/achimala/farfield/blob/main/apps/server/src/index.ts#L84-L85

const TRACE_DIR = path.resolve(process.cwd(), "traces");
const DEFAULT_WORKSPACE = path.resolve(process.cwd());

When the server is launched from a wrapper script (Windows scheduled task, systemd unit, launchd plist, Docker entrypoint, etc.), the cwd is usually some neutral spot — meaning traces/ lands wherever the launcher cd'd into, and new phone-spawned threads inherit that as their default workspace too.

In my case traces/ got dropped in the parent directory of all my repositories because the cwd I picked for the launcher was a navigation point, not a project root. I worked around it by cd'ing into a dedicated data/farfield/ directory, but that means the default workspace for new threads is now an uninteresting state dir rather than a real codebase. Per-thread cwd selection in the UI works as a workaround, but the default ends up surprising every time.

Proposal

Two new env vars, both optional, both backward-compatible:

const TRACE_DIR = path.resolve(process.env.FARFIELD_TRACE_DIR ?? path.join(process.cwd(), "traces"));
const DEFAULT_WORKSPACE = path.resolve(process.env.FARFIELD_DEFAULT_WORKSPACE ?? process.cwd());

This lets operators decouple the two concerns — pin traces under a runtime/state directory while still defaulting new threads to a real project root.

Why both

FARFIELD_TRACE_DIR alone fixes the pollution problem. Adding FARFIELD_DEFAULT_WORKSPACE is what makes the fix complete: without it, anyone using the trace-dir env var has to either (a) accept the same uninteresting default workspace, or (b) keep using cwd for the workspace and live with traces wherever cwd happens to be — defeating the point.

Alternative considered

CLI flags (--trace-dir, --workspace) instead of env vars. Either is fine; env vars feel more natural for a long-running daemon and play well with the npx -y @farfield/server@latest invocation pattern (no extra arg parsing in the launcher script needed).

Happy to send a PR if helpful — looks like a one-line change in each spot plus a README note.

Environment

• Farfield server: npx -y @farfield/server@latest (latest as of 2026-05-07)
• OS: Windows 11 Pro for Workstations
• Codex: codex-cli 0.125.0
• Tailscale-fronted setup per the README, working great otherwise — thanks for building this!