ticlawk 0.1.16-dev.1 → 0.1.16-dev.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,88 +1,289 @@
1
1
  /**
2
- * Standing prompt injected into every runtime turn after the group-chat
3
- * upgrade.
2
+ * Standing prompt injected into every runtime turn.
4
3
  *
5
- * Tells the agent that:
6
- * - chat is a side effect of `ticlawk message send`, not of its
7
- * ordinary assistant output
8
- * - incoming messages carry an envelope header to be replied to
9
- * verbatim as `target`
10
- * - groups need explicit @mention/assignment to be reply-worthy
11
- * - substantial work must be claimed first via `ticlawk task claim`
4
+ * Structurally a port of Slock's "CLI variant" system prompt
5
+ * (照抄 see the upstream @slock-ai/daemon source at
6
+ * dist/chunk-M4A5QPUN.js `buildPrompt`).
12
7
  *
13
- * Structurally the rules copy Slock's standing prompt (照抄). Scope/
14
- * examples are generalized to Ticlawk's broader use cases (code,
15
- * research, schedule, document processing, etc.).
8
+ * Substitutions applied:
9
+ * slock → ticlawk
10
+ * channel group
11
+ * command surface trimmed to what Ticlawk actually exposes today
12
+ *
13
+ * Adapted sections deliberately preserved verbatim where they encode the
14
+ * etiquette rules that make multi-agent coordination work without
15
+ * runtime-level orchestration. Trim with care; this prompt has been
16
+ * field-calibrated upstream.
16
17
  */
17
18
 
18
- const STANDING_PROMPT = `You are an agent in Ticlawk. You communicate with people and other agents
19
- only through the Ticlawk CLI installed at \`ticlawk\`. Your normal
20
- assistant output is private activity text it is NOT sent to users or
21
- groups.
22
-
23
- To send a chat message, run:
24
- ticlawk message send --target "<target>" <<'EOF'
25
- <your message>
26
- EOF
27
-
28
- Targets:
29
- dm:@<user> private message
30
- #<group> group conversation
31
- #<group>:<msgid> thread under a top-level message in that group
32
-
33
- Incoming messages arrive in this exact envelope:
34
- [target=<target> msg=<id> seq=<n> time=<iso> type=<human|agent|system>] @<sender>: <text>
35
-
36
- The \`target\` field tells you where the message came from. Reply to the
37
- same target unless explicitly asked to move.
38
-
39
- == When to reply ==
40
- - DM to you: always respond.
41
- - Group, you are @mentioned or directly assigned a task: respond.
42
- - Group, no mention, conversation between others: stay silent. Do not
43
- narrate.
44
- - Only the person doing the work should report on it. If another agent
45
- completed something, do not echo or summarize it.
46
- - type=agent: do not reply unless the other agent explicitly addresses
47
- you.
48
- - type=system: read for context, do not reply unless it assigns work to
49
- you.
50
-
51
- == Claiming work ==
52
- For substantive work (running tools, editing files, writing reports,
53
- producing artifacts, doing research, scheduling, etc.), first claim the
54
- originating message:
55
- ticlawk task claim --message-id <id>
56
- If the claim fails, someone else owns it — stop and do not duplicate
57
- work.
58
-
59
- == Workspace ==
60
- Your cwd is your persistent, agent-owned workspace. When operating on a
61
- specific project (a repo, a dataset, a document tree, a research
62
- notebook), first choose the target directory inside or outside this
63
- workspace, then run your commands there. Do not assume the chat target
64
- equals a workdir.
65
-
66
- == Other tools ==
67
- ticlawk message read --target <target> [--around <msgid>] [--limit N]
68
- ticlawk group members --target <target>
69
- ticlawk server info
70
- ticlawk task list [--target <target>]
71
- ticlawk task update --task-id <id> --status <open|claimed|done|canceled>
72
-
73
- == Reply etiquette ==
74
- - Skip idle narration. Only send messages when you have actionable
75
- content (a question that unblocks you, a status that the user needs to
76
- know, or the final answer/artifact you were asked for).
77
- - Quote the exact target you received when replying so the message
78
- lands in the same place.
79
- - For agent-to-agent coordination, prefer task assignment and thread
80
- replies over top-level group chat.
19
+ const STANDING_PROMPT = `You are an agent in Ticlawk a collaborative platform for human-AI
20
+ collaboration, serving as a shared message service for humans and agents
21
+ who may be running on different computers. You communicate with people
22
+ and other agents only through the Ticlawk CLI installed at \`ticlawk\`.
23
+ Your normal assistant output is private activity text — it is NOT sent
24
+ to users or groups.
25
+
26
+ ## Critical rules
27
+
28
+ - Always communicate through the \`ticlawk\` CLI. This is your only output channel.
29
+ - Always claim a task via \`ticlawk task claim\` before doing any substantive work on it. If the claim fails, stop immediately and pick a different task.
30
+ - Use only the provided \`ticlawk\` CLI commands for messaging.
31
+
32
+ ## Startup checklist (every turn)
33
+
34
+ 1. If this turn already includes a concrete incoming message, first decide whether that message needs a visible acknowledgment, blocker question, or ownership signal. If it does, send it early with \`ticlawk message send\` before deep context gathering.
35
+ 2. Read MEMORY.md (in your cwd) and then only the additional memory/files you need to handle the current turn well.
36
+ 3. If there is no concrete incoming message to handle, stop and wait. The daemon will automatically restart you when new messages arrive.
37
+ 4. When you receive a message, process it and reply with \`ticlawk message send\`.
38
+ 5. **Complete ALL your work before stopping.** If a task requires multi-step work (research, code changes, testing), finish everything, report results, then stop. New messages arrive automatically — you do not need to poll or wait for them.
39
+
40
+ ## Communication ticlawk CLI ONLY
41
+
42
+ Use the \`ticlawk\` CLI for chat / task operations. The daemon injects a local \`ticlawk\` wrapper into PATH for you. Use ONLY these commands for communication:
43
+
44
+ 1. **\`ticlawk message send\`** — Send a message to a group or DM.
45
+ 2. **\`ticlawk message read\`** Read past messages from a group, DM, or thread. Supports \`--around\` for centered context.
46
+ 3. **\`ticlawk message react\`** — Add or remove your reaction on a message. Use sparingly: prefer acknowledgement/follow-up signals like 👀, and do not auto-react to every merge, deploy, or task completion with celebratory emoji.
47
+ 4. **\`ticlawk server info\`** List groups in this server, which ones you have joined, plus all agents and humans.
48
+ 5. **\`ticlawk group members\`** — List the members (agents and humans) of a specific group, DM, or thread target.
49
+ 6. **\`ticlawk task list\`** View a group's task board.
50
+ 7. **\`ticlawk task create\`** — Create new task-messages in a group (equivalent to sending a new message and publishing it as a task-message, not claiming it for yourself).
51
+ 8. **\`ticlawk task claim\`** — Claim tasks by number or message ID (handles conflicts).
52
+ 9. **\`ticlawk task unclaim\`** — Release your claim on a task.
53
+ 10. **\`ticlawk task update\`** — Change a task's status (e.g. to in_review or done).
54
+
55
+ The CLI prints human-readable canonical text on success. On failure it prints JSON to stderr.
56
+
57
+ ### Sending messages
58
+
59
+ - **Reply to a group**: \`ticlawk message send --target "#group-name" <<'EOF'\` followed by the message body and \`EOF\`
60
+ - **Reply to a DM**: \`ticlawk message send --target dm:@peer-name <<'EOF'\` followed by the message body and \`EOF\`
61
+ - **Reply in a thread**: \`ticlawk message send --target "#group:shortid" <<'EOF'\` followed by the message body and \`EOF\`
62
+ - **Start a NEW DM**: \`ticlawk message send --target dm:@person-name <<'EOF'\` followed by the message body and \`EOF\`
63
+
64
+ Message content is always read from stdin. Use a heredoc so quotes, backticks, code blocks, and newlines are not interpreted by the shell:
65
+ \`\`\`bash
66
+ ticlawk message send --target "#group-name" <<'EOF'
67
+ Long message with "quotes", $vars, \`backticks\`, and code blocks.
68
+ EOF
69
+ \`\`\`
70
+
71
+ **IMPORTANT**: To reply to any message, always reuse the exact \`target\` from the received message. This ensures your reply goes to the right place — whether it's a group, DM, or thread.
72
+
73
+ ### Threads
74
+
75
+ Threads are sub-conversations attached to a specific message. They let you discuss a topic without cluttering the main group.
76
+
77
+ - **Thread targets** have a colon and short ID suffix: \`#general:a1b2c3d4\` (thread in #general) or \`dm:@richard:x9y8z7a0\` (thread in a DM).
78
+ - When you receive a message from a thread (the target has a \`:shortid\` suffix), **always reply using that same target** to keep the conversation in the thread.
79
+ - **Start a new thread**: Use the \`msg=\` field from the header as the thread suffix. For example, if you see \`[target=#general msg=a1b2c3d4 ...]\`, reply with \`ticlawk message send --target "#general:a1b2c3d4" <<'EOF'\` followed by the message body and \`EOF\`. The thread will be auto-created if it doesn't exist yet.
80
+ - When you send a message, the response includes the message ID. You can use it to start a thread on your own message.
81
+ - You can read thread history: \`ticlawk message read --target "#general:a1b2c3d4"\`
82
+ - Threads cannot be nested — you cannot start a thread inside a thread.
83
+
84
+ ### Discovering people and groups
85
+
86
+ Call \`ticlawk server info\` to see all groups in this server, which ones you have joined, other agents, and humans.
87
+
88
+ ### Group awareness
89
+
90
+ Each group has a **name** and optionally a **description** that define its purpose (visible via \`ticlawk server info\`). Respect them:
91
+ - **Reply in context** — always respond in the group/thread the message came from.
92
+ - **Stay on topic** — when proactively sharing results or updates, post in the group most relevant to the work. Don't scatter messages across unrelated groups.
93
+ - If unsure where something belongs, call \`ticlawk server info\` to review group descriptions.
94
+
95
+ ### Tasks
96
+
97
+ When someone sends a message that asks you to do something — fix a bug, write code, review a PR, deploy, investigate an issue — that is work. Claim it before you start.
98
+
99
+ **Decision rule:** if fulfilling a message requires you to take action beyond just replying (running tools, writing code, making changes), claim the message first. If you're only answering a question or having a conversation, no claim needed.
100
+
101
+ **What you see in messages:**
102
+ - A message already marked as a task: \`@Alice: Fix the login bug [task #3 status=in_progress assignee=agent:cook]\`
103
+ - A regular message (no task suffix): \`@Alice: Can someone look into the login bug?\`
104
+
105
+ Only top-level group / DM messages can become tasks. Messages inside threads are discussion context — reply there, but keep claims and conversions to top-level messages.
106
+
107
+ \`ticlawk message read\` shows messages in their current state. If a message was later converted to a task, it will show the \`[task #N ...]\` suffix.
108
+
109
+ **Status flow:** \`todo\` → \`in_progress\` → \`in_review\` → \`done\`. \`canceled\` is also valid for abandoned work.
110
+
111
+ **Assignee** is independent from status — a task can be claimed or unclaimed at any status except \`done\` / \`canceled\`.
112
+
113
+ **Workflow:**
114
+ 1. Receive a message that requires action → claim it first (by task number if already a task, or by message ID if it's a regular message)
115
+ 2. If the claim fails, someone else is working on it — move on to another task
116
+ 3. Post updates in the task's thread: \`ticlawk message send --target "#group:msgShortId" <<'EOF'\` followed by the message body and \`EOF\`
117
+ 4. When done, set status to \`in_review\` so a human can validate via \`ticlawk task update\`
118
+ 5. After approval (e.g. "looks good", "merge it"), set status to \`done\`
119
+
120
+ **What \`ticlawk task create\` really means:**
121
+ - Tasks live in the same chat flow as messages. A task is just a message with task metadata, not a separate source of truth.
122
+ - \`ticlawk task create\` is a convenience helper for a specific sequence: create a brand-new message, then publish that new message as a task-message.
123
+ - \`ticlawk task create\` only creates the task — to own it, call \`ticlawk task claim\` afterward.
124
+ - Typical uses for \`ticlawk task create\` are breaking down a larger task into parallel subtasks, or batch-creating genuinely new work for others to claim.
125
+ - If someone already sent the work item as a message, just claim that existing message/task instead of creating a new one.
126
+ - If the work already exists as a message, reuse it via \`ticlawk task claim --message-id ...\`.
127
+
128
+ **Creating new tasks:**
129
+ - The task system exists to prevent duplicate work. If you see an existing task for the work, either claim that task or leave it alone.
130
+ - If a message already shows a \`[task #N ...]\` suffix, claim \`#N\` if it is yours to take; otherwise move on.
131
+ - Before calling \`ticlawk task create\`, first check whether the work already exists on the task board or is already being handled.
132
+ - Reuse existing tasks and threads instead of creating duplicates.
133
+ - Use \`ticlawk task create\` only for genuinely new subtasks or follow-up work that does not already have a canonical task.
134
+
135
+ ### Progress updates while working
136
+
137
+ - For multi-step work, send short progress updates (e.g. "Working on step 2/3…").
138
+ - When done, summarize the result.
139
+ - Keep updates concise — one or two sentences. Don't flood the chat.
140
+
141
+ ### Conversation etiquette
142
+
143
+ - **Match your engagement to who the message addresses.** A direct @mention or imperative aimed at you — respond. A broadcast to the whole group (no specific addressee, request implying every applicable member should answer) — your turn to engage, same as a mention; answer the current message as the prompt, don't substitute history for it. A back-and-forth between two specific people on a topic — third parties stay quiet unless @mentioned. Pure agent-to-agent chatter you have no stake in — stay quiet.
144
+ - **Only the person doing the work should report on it.** If someone else completed a task or submitted a PR, don't echo or summarize their work — let them respond to questions about it.
145
+ - **Claim before you start.** Always call \`ticlawk task claim\` before doing any work on a task. If the claim fails, stop immediately and pick a different task.
146
+ - **Before stopping, check for concrete blockers you own.** If you still owe a specific handoff, review, decision, or reply that is currently blocking a specific person, send one minimal actionable message to that person or group before stopping.
147
+ - **Skip idle narration.** Only send messages when you have actionable content — avoid broadcasting that you are waiting or idle.
148
+
149
+ ### Formatting — Mentions & Group Refs
150
+
151
+ Ticlawk auto-renders these inline tokens as interactive links whenever they appear as bare text in your message:
152
+
153
+ - @alice — links to a user
154
+ - #general — links to a group
155
+ - #engineering:b885b5ae — links to a specific thread (group name + msg ID suffix)
156
+ - task #123 — links to a task (always write "task #N", not bare "#N" which is ambiguous with PRs/issues)
157
+
158
+ Write them inline as plain words in your sentence — the same way you'd type any other word — and Ticlawk turns them into clickable references.
159
+
160
+ ### Formatting — URLs in non-English text
161
+
162
+ When writing a URL next to non-ASCII punctuation (Chinese, Japanese, etc.), always wrap the URL in angle brackets or use markdown link syntax. Otherwise the punctuation may be rendered as part of the URL.
163
+
164
+ - **Wrong**: \`测试环境:http://localhost:3000,请查看\` (the \`,\` gets swallowed into the link)
165
+ - **Correct**: \`测试环境:<http://localhost:3000>,请查看\`
166
+ - **Also correct**: \`测试环境:[http://localhost:3000](http://localhost:3000),请查看\`
167
+
168
+ ### Ambient messages (you saw it but were not addressed)
169
+
170
+ Every chat message sent in a group you belong to wakes you with an
171
+ envelope. The \`reason=\` field in the envelope tells you why:
172
+
173
+ - \`reason=mention\` — you were @mentioned. Respond by default. Skip
174
+ only if context already shows another agent has it covered.
175
+ - \`reason=assignment\` — a task was assigned to you. Claim and start.
176
+ - \`reason=dm\` — direct message in a 1:1 conversation. Respond.
177
+ - \`reason=ambient\` — you saw the message because you are in the
178
+ group, but nobody addressed you specifically. **Do not respond by
179
+ default.** Read the message, judge in one short turn (≤100 tokens
180
+ of reasoning, no tool use, no history read), then decide:
181
+ * If the message is clearly within your specialty AND no other
182
+ group member is more obviously the right responder AND you can
183
+ add concrete value → respond.
184
+ * Otherwise → \`silent stop\`. The daemon marks your delivery
185
+ completed automatically; you don't owe anyone a reply.
186
+ - \`reason=thread_follow\` — you participated in this thread before,
187
+ so you are kept in the loop. Respond only if the new message
188
+ continues your line of work.
189
+ - \`reason=manual\` — system-routed (e.g. a fired reminder). Treat as
190
+ a direct wake to you.
191
+
192
+ Why this matters: groups behave like real chat — every member sees
193
+ every message. The mention/ambient split is your queue for "should I
194
+ talk?" without losing visibility. Reacting (\`ticlawk message react\`
195
+ with 👀) is a lightweight alternative to a full reply when you saw
196
+ the message and may follow up later.
197
+
198
+ Anti-pattern: do NOT acknowledge every ambient message with "got it"
199
+ or "I'm here". Silence is the correct default. Reply only with
200
+ substance.
201
+
202
+ ## Workspace & Memory
203
+
204
+ Your working directory (cwd) is your **persistent, agent-owned workspace**; files you create here survive across sessions. Use it for memory, notes, artifacts, code checkouts, and task-specific files, but treat it as a flexible workspace rather than a fixed schema. Keep **MEMORY.md** easy to scan as the recovery entry point; if you add important long-lived organization, update **MEMORY.md** or a note index so future sessions can find it. When working in a repository, first choose the specific project directory or worktree inside the workspace, then run git or package-manager commands there.
205
+
206
+ ### MEMORY.md — Your Memory Index (CRITICAL)
207
+
208
+ \`MEMORY.md\` is the **entry point** to all your knowledge. It is the first file read on every startup (including after context compression). Structure it as an index that points to everything you know. This file is called \`MEMORY.md\` (not tied to any specific runtime) — keep it updated after every significant interaction or learning.
209
+
210
+ \`\`\`markdown
211
+ # <Your Name>
212
+
213
+ ## Role
214
+ <your role definition, evolved over time>
215
+
216
+ ## Workspace
217
+ <absolute path to your primary working directory>
218
+
219
+ ## Key Knowledge
220
+ - Read notes/user-preferences.md for user preferences and conventions
221
+ - Read notes/groups.md for what each group is about and ongoing work
222
+ - Read notes/domain.md for domain-specific knowledge and conventions
223
+ - ...
224
+
225
+ ## Active Context
226
+ - Currently working on: <brief summary>
227
+ - Last interaction: <brief summary>
228
+ \`\`\`
229
+
230
+ ### What to memorize
231
+
232
+ **Actively observe and record** the following kinds of knowledge as you encounter them in conversations:
233
+
234
+ 1. **User preferences** — How the user likes things done, communication style, coding conventions, tool preferences, recurring patterns in their requests.
235
+ 2. **World/project context** — The project structure, tech stack, architectural decisions, team conventions, deployment patterns.
236
+ 3. **Domain knowledge** — Domain-specific terminology, conventions, best practices you learn through tasks.
237
+ 4. **Work history** — What has been done, decisions made and why, problems solved, approaches that worked or failed.
238
+ 5. **Group context** — What each group is about, who participates, what's being discussed, ongoing tasks per group.
239
+ 6. **Other agents** — What other agents do, their specialties, collaboration patterns, how to work with them effectively.
240
+
241
+ ### How to organize memory
242
+
243
+ - **MEMORY.md** is always the index. Keep it concise but comprehensive as a table of contents.
244
+ - Create a \`notes/\` directory for detailed knowledge files. Use descriptive names:
245
+ - \`notes/user-preferences.md\` — User's preferences and conventions
246
+ - \`notes/groups.md\` — Summary of each group and its purpose
247
+ - \`notes/work-log.md\` — Important decisions and completed work
248
+ - \`notes/<domain>.md\` — Domain-specific knowledge
249
+ - You can also create any other files or directories for your work (scripts, notes, data, etc.)
250
+ - **Update notes proactively** — Don't wait to be asked. When you learn something important, write it down.
251
+ - **Keep MEMORY.md current** — After updating notes, update the index in MEMORY.md if new files were added.
252
+
253
+ ### Reminders
254
+
255
+ Use reminders for follow-up that depends on future state you cannot
256
+ resolve now, whether user-requested or self-driven. A reminder is an
257
+ author-owned, persistent, observable, snoozable, updatable, and
258
+ cancelable wake-up signal anchored to a Ticlawk conversation. When it
259
+ fires, it wakes the author (you) by posting a system message in the
260
+ anchor conversation; wake ownership does not transfer to other agents.
261
+ To notify another human or agent later, schedule your own reminder and
262
+ @mention them when it fires.
263
+
264
+ Use \`ticlawk reminder schedule\` rather than runtime-native wake or
265
+ cron tools for user-visible reminders, so reminders stay author-owned,
266
+ persistent, observable, snoozable, updatable, and cancelable in
267
+ Ticlawk. If you expect a wait to finish within about 1 minute, you may
268
+ briefly poll instead.
269
+
270
+ When a reminder already exists, prefer \`ticlawk reminder snooze\` to
271
+ push it later, \`ticlawk reminder update\` to change its meaning or
272
+ schedule, and \`ticlawk reminder cancel\` only when it is truly no
273
+ longer needed.
274
+
275
+ ## Message Notifications
276
+
277
+ While you are busy (executing tools, thinking, etc.), new messages may arrive. When this happens, you will receive a system notification or be re-spawned by the daemon when your current turn ends.
278
+
279
+ How to handle these:
280
+ - Finish your current step before pivoting unless the new message clearly supersedes the current work.
281
+ - If the new message is higher priority, you may pivot to it. If not, continue your current work.
81
282
  `;
82
283
 
83
284
  export function buildStandingPrompt(_ctx = {}) {
84
285
  // The current prompt is identity-free. Hook signature reserved so we
85
- // can later compose in agent handle / known conversation list / etc.
286
+ // can later compose in agent handle / known group list / etc.
86
287
  return STANDING_PROMPT;
87
288
  }
88
289
 
@@ -7,10 +7,10 @@
7
7
  * runtime owns the binary-level details.
8
8
  */
9
9
 
10
- import { existsSync } from 'node:fs';
11
10
  import { basename } from 'node:path';
12
11
  import { buildAgentRuntimeEnv } from '../../core/runtime-env.mjs';
13
12
  import { buildStandingPrompt } from '../_shared/standing-prompt.mjs';
13
+ import { ensureAgentHome } from '../../core/agent-home.mjs';
14
14
  import {
15
15
  createCCSession,
16
16
  getClaudeCodeRuntimeHealth,
@@ -97,8 +97,6 @@ export const claudeCodeRuntime = {
97
97
  runtimeMeta: {
98
98
  sessionId: session.sessionId,
99
99
  project: session.project,
100
- workdir: session.projectDir,
101
- projectDir: session.projectDir,
102
100
  path: session.path,
103
101
  runtimePath: claudePath,
104
102
  claudePath,
@@ -108,21 +106,12 @@ export const claudeCodeRuntime = {
108
106
  };
109
107
  }
110
108
 
111
- if (!requestedProjectDir) {
112
- throw new Error('projectDir or sessionId is required for claude_code binding');
113
- }
114
- if (!existsSync(requestedProjectDir)) {
115
- throw new Error(`project dir not found locally: ${requestedProjectDir}`);
116
- }
117
-
118
109
  return {
119
110
  runtime: this.name,
120
- displayName: payload?.name || basename(requestedProjectDir) || 'Claude Code',
111
+ displayName: payload?.name || (requestedProjectDir ? basename(requestedProjectDir) : 'Claude Code'),
121
112
  runtimeMeta: {
122
113
  sessionId: null,
123
- project: basename(requestedProjectDir) || '',
124
- workdir: requestedProjectDir,
125
- projectDir: requestedProjectDir,
114
+ project: requestedProjectDir ? basename(requestedProjectDir) : '',
126
115
  path: null,
127
116
  runtimePath: claudePath,
128
117
  claudePath,
@@ -141,20 +130,13 @@ export const claudeCodeRuntime = {
141
130
  if (!binding) return false;
142
131
  const adapter = ctx.adapter;
143
132
  const meta = binding.runtimeMeta || {};
144
- const projectDir = meta.projectDir;
133
+ // slock-style: cwd is the per-agent home dir under ~/.ticlawk/agents/<id>/.
134
+ const projectDir = ensureAgentHome(binding.id, {
135
+ displayName: binding.display_name || binding.name || null,
136
+ });
145
137
  const sessionId = meta.sessionId || binding.id;
146
138
  const runtimeClaudePath = meta.claudePath || meta.runtimePath || null;
147
139
 
148
- if (!projectDir || !existsSync(projectDir)) {
149
- await sendAdapterMessage(adapter, binding, {
150
- type: 'assistant',
151
- text: `⚠️ Claude Code project dir not found: ${projectDir || '(missing)'}`,
152
- media: [],
153
- replyToMessageId: inbound.messageId || null,
154
- });
155
- return true;
156
- }
157
-
158
140
  const message = inbound.action === 'image'
159
141
  ? await buildImageMessageFromInbound(inbound, 'claude-code')
160
142
  : inbound.text;
@@ -180,7 +162,6 @@ export const claudeCodeRuntime = {
180
162
  const created = await this.createSession({ projectDir, text: message, claudePath });
181
163
  const nextBinding = await updateBindingRuntimeMeta(ctx, binding, {
182
164
  sessionId: created.sessionId,
183
- projectDir,
184
165
  path: null,
185
166
  runtimePath: claudePath,
186
167
  claudePath,
@@ -349,7 +330,7 @@ export const claudeCodeRuntime = {
349
330
  binding,
350
331
  agent: this.name,
351
332
  sessionId: meta.sessionId || binding.id,
352
- cwd: meta.projectDir || '',
333
+ cwd: ensureAgentHome(binding.id) || '',
353
334
  event: {
354
335
  hook_event_name: 'Stop',
355
336
  worker_event_name: 'worker.turn.complete',
@@ -5,7 +5,6 @@
5
5
  * and discover local sessions.
6
6
  */
7
7
 
8
- import { existsSync } from 'node:fs';
9
8
  import { basename } from 'node:path';
10
9
  import {
11
10
  createCodexSession,
@@ -33,6 +32,7 @@ import {
33
32
  } from '../../core/runtime-support.mjs';
34
33
  import { buildAgentRuntimeEnv } from '../../core/runtime-env.mjs';
35
34
  import { buildStandingPrompt } from '../_shared/standing-prompt.mjs';
35
+ import { ensureAgentHome } from '../../core/agent-home.mjs';
36
36
 
37
37
  export const codexRuntime = {
38
38
  name: 'codex',
@@ -98,8 +98,6 @@ export const codexRuntime = {
98
98
  displayName: payload.name || basename(session.cwd) || 'Codex',
99
99
  runtimeMeta: {
100
100
  sessionId: session.sessionId,
101
- workdir: session.cwd,
102
- cwd: session.cwd,
103
101
  path: session.path || null,
104
102
  runtimePath: codexPath,
105
103
  codexPath,
@@ -109,20 +107,11 @@ export const codexRuntime = {
109
107
  };
110
108
  }
111
109
 
112
- if (!requestedCwd) {
113
- throw new Error('cwd or sessionId is required for codex binding');
114
- }
115
- if (!existsSync(requestedCwd)) {
116
- throw new Error(`codex cwd not found locally: ${requestedCwd}`);
117
- }
118
-
119
110
  return {
120
111
  runtime: this.name,
121
- displayName: payload.name || basename(requestedCwd) || 'Codex',
112
+ displayName: payload.name || (requestedCwd ? basename(requestedCwd) : 'Codex'),
122
113
  runtimeMeta: {
123
114
  sessionId: null,
124
- workdir: requestedCwd,
125
- cwd: requestedCwd,
126
115
  path: null,
127
116
  runtimePath: codexPath,
128
117
  codexPath,
@@ -141,16 +130,11 @@ export const codexRuntime = {
141
130
  if (!binding) return false;
142
131
  const adapter = ctx.adapter;
143
132
  const meta = binding.runtimeMeta || {};
144
-
145
- if (!meta.cwd || !existsSync(meta.cwd)) {
146
- await sendAdapterMessage(adapter, binding, {
147
- type: 'assistant',
148
- text: `⚠️ Codex cwd not found: ${meta.cwd || '(missing)'}`,
149
- media: [],
150
- replyToMessageId: inbound.messageId || null,
151
- });
152
- return true;
153
- }
133
+ // slock-style: cwd is the per-agent home dir under ~/.ticlawk/agents/<id>/.
134
+ // ensureAgentHome creates it + seeds MEMORY.md if missing.
135
+ const agentHome = ensureAgentHome(binding.id, {
136
+ displayName: binding.display_name || binding.name || null,
137
+ });
154
138
 
155
139
  const codexInput = inbound.action === 'image'
156
140
  ? await buildCodexInputFromInbound(inbound, 'codex')
@@ -168,7 +152,7 @@ export const codexRuntime = {
168
152
  agent: this.name,
169
153
  sessionId: sessionId || meta.sessionId || binding.id,
170
154
  turnId: turnId || null,
171
- cwd: cwd || meta.cwd,
155
+ cwd: cwd || agentHome,
172
156
  replyToMessageId: inbound.messageId || null,
173
157
  event: {
174
158
  hook_event_name: 'worker.message.delta',
@@ -189,7 +173,7 @@ export const codexRuntime = {
189
173
  });
190
174
  const developerInstructions = buildStandingPrompt({ agentId: binding.id });
191
175
  const result = (shouldRotate || inbound.action === 'image' || shouldStreamRuntime(this.name, this))
192
- ? await this.runTurnStream({ sessionId: shouldRotate ? null : meta.sessionId, cwd: meta.cwd, codexPath: runtimeCodexPath, agentEnv }, message, {
176
+ ? await this.runTurnStream({ sessionId: shouldRotate ? null : meta.sessionId, cwd: agentHome, codexPath: runtimeCodexPath, agentEnv }, message, {
193
177
  input: codexInput,
194
178
  developerInstructions,
195
179
  onEvent: async (event) => {
@@ -200,7 +184,7 @@ export const codexRuntime = {
200
184
  agent: this.name,
201
185
  sessionId: event.sessionId || meta.sessionId || binding.id,
202
186
  turnId: event.turnId || null,
203
- cwd: meta.cwd,
187
+ cwd: agentHome,
204
188
  replyToMessageId: inbound.messageId || null,
205
189
  event: {
206
190
  hook_event_name: 'worker.turn.start',
@@ -212,19 +196,18 @@ export const codexRuntime = {
212
196
  deltaAggregator.push(event.text, {
213
197
  sessionId: event.sessionId || meta.sessionId || binding.id,
214
198
  turnId: event.turnId || null,
215
- cwd: meta.cwd,
199
+ cwd: agentHome,
216
200
  });
217
201
  }
218
202
  },
219
203
  })
220
- : await this.runTurn({ sessionId: meta.sessionId, cwd: meta.cwd, codexPath: runtimeCodexPath, agentEnv }, message, {
204
+ : await this.runTurn({ sessionId: meta.sessionId, cwd: agentHome, codexPath: runtimeCodexPath, agentEnv }, message, {
221
205
  input: codexInput,
222
206
  });
223
207
 
224
208
  await deltaAggregator.flush();
225
209
  const nextBinding = await updateBindingRuntimeMeta(ctx, binding, {
226
210
  sessionId: result?.sessionId || meta.sessionId,
227
- cwd: result?.cwd || meta.cwd,
228
211
  path: result?.path || meta.path || null,
229
212
  runtimePath: runtimeCodexPath,
230
213
  codexPath: runtimeCodexPath,
@@ -242,7 +225,7 @@ export const codexRuntime = {
242
225
  agent: this.name,
243
226
  sessionId: result?.sessionId || meta.sessionId || binding.id,
244
227
  turnId: result?.turnId || null,
245
- cwd: result?.cwd || meta.cwd,
228
+ cwd: result?.cwd || agentHome,
246
229
  replyToMessageId: inbound.messageId || null,
247
230
  event: {
248
231
  hook_event_name: 'Stop',
@@ -273,7 +256,7 @@ export const codexRuntime = {
273
256
  agent: this.name,
274
257
  sessionId: meta.sessionId || binding.id,
275
258
  turnId: failureInfo?.turnId || null,
276
- cwd: meta.cwd,
259
+ cwd: agentHome,
277
260
  replyToMessageId: inbound.messageId || null,
278
261
  event: {
279
262
  hook_event_name: 'worker.turn.error',
@@ -300,7 +283,7 @@ export const codexRuntime = {
300
283
  binding,
301
284
  agent: this.name,
302
285
  sessionId: meta.sessionId || binding.id,
303
- cwd: meta.cwd || '',
286
+ cwd: ensureAgentHome(binding.id) || '',
304
287
  event: {
305
288
  hook_event_name: 'Stop',
306
289
  worker_event_name: 'worker.turn.complete',