pastilhasandClaude Opus 4.8
1824f53c89
officer built the whole PtyInitConfig: it read the owner's SHELL (defaulting to /bin/zsh), added `-i`, read their HOME, expanded `~` against it, and hardcoded `host: true`. none of that is a proxy's business — the sidecar is the process that calls pty.spawn, so it is the one that should know what to spawn and where. the config now carries only what the bridge actually knows: sessionId, the folder the panel was opened on, and the client's cols/rows. shell, args, home and cwd resolution moved into the sidecar. home comes from HOME_DIR ?? HOME, mirroring data-path.ts:getOwnerHomeDir — terminal was the one host-executing surface reading process.env.HOME directly, which is identical here and divergent anywhere HOME_DIR is set to something else. deleted the bwrap sandbox branch rather than moving it. it was selected by `config.host`, which officer hardcoded to true, so it never ran — and it expected `shell` to contain a fully-built bwrap command that nothing on either side ever built. it could not have worked. a terminal here is the owner's own shell on the owner's own machine by design (platform/CLAUDE.md), so there is no jail to preserve. its ensureUserFiles half duplicated api/users/provision.ts:seedShellConfigs, which is the live seeder of those same templates and stays. also deleted the 'cwd' handler that turned a message into `cd <path>\r` typed at the shell. no frontend has ever sent that message — the browser composes its own cd — so it was unreachable, and synthesizing keystrokes is not something a relay should do. the integration test pins SHELL and HOME_DIR now that the sidecar reads them, and asserts the shell starts in the resolved `~` rather than officer having resolved it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>