agent-dag 1.35.8 → 1.35.9
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.
package/dist/web/index.html
CHANGED
|
@@ -40,7 +40,7 @@
|
|
|
40
40
|
document.documentElement.setAttribute("data-theme", stored === "light" ? "light" : "dark");
|
|
41
41
|
})();
|
|
42
42
|
</script>
|
|
43
|
-
<script type="module" crossorigin src="/assets/index-
|
|
43
|
+
<script type="module" crossorigin src="/assets/index-Z4NdQ28G.js"></script>
|
|
44
44
|
<link rel="stylesheet" crossorigin href="/assets/index-DUPCQ3ZT.css">
|
|
45
45
|
</head>
|
|
46
46
|
<body>
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "agent-dag",
|
|
3
|
-
"version": "1.35.
|
|
3
|
+
"version": "1.35.9",
|
|
4
4
|
"description": "Live deck of Claude Code and Codex agents — watch parallel subagents fork, call tools, and return on one calm canvas. Also available as npx ccdeck and npx agent-dag.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
package/src/server/index.mjs
CHANGED
|
@@ -1005,7 +1005,7 @@ export function codexObjToPayload(obj, sid, cwd) {
|
|
|
1005
1005
|
return { ...base, hook_event_name: "PreToolUse", tool_name: pl.name ?? "tool", tool_input: input, tool_use_id: pl.call_id, model };
|
|
1006
1006
|
}
|
|
1007
1007
|
if (pl.type === "custom_tool_call") {
|
|
1008
|
-
return { ...base, hook_event_name: "PreToolUse", tool_name: pl.name ?? "tool", tool_input:
|
|
1008
|
+
return { ...base, hook_event_name: "PreToolUse", tool_name: pl.name ?? "tool", tool_input: codexCustomToolInput(pl.name, pl.input), tool_use_id: pl.call_id, model };
|
|
1009
1009
|
}
|
|
1010
1010
|
// #397: the outcome, not just the fact that an outcome arrived. This used
|
|
1011
1011
|
// to hardcode "PostToolUse" for both output types, and the reducer derives
|
|
@@ -1027,6 +1027,60 @@ export function codexObjToPayload(obj, sid, cwd) {
|
|
|
1027
1027
|
return null;
|
|
1028
1028
|
}
|
|
1029
1029
|
|
|
1030
|
+
/**
|
|
1031
|
+
* Wrap a `custom_tool_call`'s raw input under the key that describes what it
|
|
1032
|
+
* actually is.
|
|
1033
|
+
*
|
|
1034
|
+
* WHY THIS IS NOT JUST `{ patch: input }` ANY MORE (#417). Codex's
|
|
1035
|
+
* `custom_tool_call` container carries a bare string and nothing that says what
|
|
1036
|
+
* kind of string it is — the tool's NAME is the only discriminator. When this
|
|
1037
|
+
* branch was written the container had exactly one inhabitant, `apply_patch`,
|
|
1038
|
+
* so it hardcoded `patch` and was right. It is no longer the only inhabitant,
|
|
1039
|
+
* and on 0.147 it is not even the common one:
|
|
1040
|
+
*
|
|
1041
|
+
* CLI custom_tool_call name count
|
|
1042
|
+
* 0.144.5 exec 77
|
|
1043
|
+
* 0.144.5 apply_patch 2
|
|
1044
|
+
* 0.147.0 exec 6
|
|
1045
|
+
*
|
|
1046
|
+
* Eighty-three shell scripts were therefore filed on the deck as patches. The
|
|
1047
|
+
* client's `commandStringOf` reads `cmd` / `command` / `script` and never
|
|
1048
|
+
* `patch`, so no Codex call could show what it ran; `extractFilePath` mean-
|
|
1049
|
+
* while reads `patch` and tried to find a `*** Update File:` header in a
|
|
1050
|
+
* JavaScript program. Keying off the name fixes both directions at once.
|
|
1051
|
+
*
|
|
1052
|
+
* WHY `exec` GETS `script` AND NOT `command`. Because it is not a command. The
|
|
1053
|
+
* `exec` tool takes a small JavaScript program that calls into a `tools.*` API
|
|
1054
|
+
* — 83 of 83 inputs on this machine start with `const `, none parses as JSON,
|
|
1055
|
+
* all are multi-line — and Codex's own result wrapper calls it one, prefixing
|
|
1056
|
+
* the output with "Script completed" / "Script failed" rather than an exit code
|
|
1057
|
+
* (the line #397 reads). Filing a program under `command` would make the deck
|
|
1058
|
+
* draw the first token of the program as the command that ran, which is the
|
|
1059
|
+
* word `const` on every Codex call in the session. `script` is both true and
|
|
1060
|
+
* already understood by the client, which digs the real command out of the
|
|
1061
|
+
* program from there.
|
|
1062
|
+
*
|
|
1063
|
+
* WHY THE FALLBACK IS `input` AND NOT A GUESS. A name this function has never
|
|
1064
|
+
* heard of is a string whose meaning is unknown, and the one thing worse than
|
|
1065
|
+
* showing it under a neutral key is showing it under a confident wrong one —
|
|
1066
|
+
* that is the whole of this bug, repeated. `input` claims nothing; the tool's
|
|
1067
|
+
* own name still reaches the bubble, so an unrecognised Codex tool degrades to
|
|
1068
|
+
* "a tool I cannot read the arguments of" instead of "a patch".
|
|
1069
|
+
*/
|
|
1070
|
+
const CODEX_CUSTOM_TOOL_INPUT_KEY = {
|
|
1071
|
+
// A `*** Begin Patch … *** End Patch` document (2/2 observed, both 0.144.5).
|
|
1072
|
+
// Unchanged, and it has to stay unchanged: the client's extractFilePath()
|
|
1073
|
+
// pulls the edited file's path out of `input.patch` for the sub-bubble.
|
|
1074
|
+
apply_patch: "patch",
|
|
1075
|
+
// A JavaScript program. See above.
|
|
1076
|
+
exec: "script",
|
|
1077
|
+
};
|
|
1078
|
+
|
|
1079
|
+
function codexCustomToolInput(name, input) {
|
|
1080
|
+
const key = CODEX_CUSTOM_TOOL_INPUT_KEY[name] ?? "input";
|
|
1081
|
+
return { [key]: input };
|
|
1082
|
+
}
|
|
1083
|
+
|
|
1030
1084
|
/**
|
|
1031
1085
|
* The text parts of a Codex tool result, in the order Codex wrote them.
|
|
1032
1086
|
*
|